vpnkit impact on Windows TCP Stack ?
Nobody has claimed this yet.
- Dominant language
- OCaml
- Stars
- 1.2k
- Forks
- 214
- PR merge metrics
- No merged PRs in 30d
Description
I'm having an issue with a specific database engine (proprietary) inside a docker container on windows (LCOW).
I've managed to narrow it down to the use of vpnkit.
Here is the situation:
I start the container with few ports forwarded -p 6000:6000 -p 6001:6001 -p 1025-1035:1025-1035
I spawn an ODBC client on my Windows host, connect it to localhost, and query this db (multiple insert, approx. 4000 ).
At some point the connection is closed, with a generic ODBC exception. Neither the db engine, nor the odbc client logs explains the situation, it seems related to a network issue.
Tail of the last TCP exchanges using localhost/vpnkit

When I do the same thing but connect the ODBC client to the hyper-v VM (MobyLinux) ip (in my case 10.0.75.2), everything works fine.
I'm guessing vpnkit has an impact on the network between the db engine and the odbc client, but it's not clear what exactly. I've read vpnkit has some sort of protocol over-the-top to handle connection close. Is there an impact on packet size ? MTU ? or anything else.
I also suppose the db engine or the odbc client is not quite resilient to network perturbation.
docker version
Client:
Version: 18.06.1-ce
API version: 1.38
Go version: go1.10.3
Git commit: e68fc7a
Built: Tue Aug 21 17:21:34 2018
OS/Arch: windows/amd64
Experimental: false
Server:
Engine:
Version: 18.06.1-ce
API version: 1.38 (minimum version 1.12)
Go version: go1.10.3
Git commit: e68fc7a
Built: Tue Aug 21 17:29:02 2018
OS/Arch: linux/amd64
Experimental: false
docker info
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 28
Server Version: 18.06.1-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
seccomp
Profile: default
Kernel Version: 4.9.93-linuxkit-aufs
Operating System: Docker for Windows
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.934GiB
Name: linuxkit-00155d4b0153
ID: HGXK:WEF3:L5GZ:NIOG:MSZI:UB4T:YLNV:67ZA:QFUI:VIDD:WOVI:LK6C
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 30
Goroutines: 62
System Time: 2018-09-28T14:58:48.1464452Z
EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Thank you
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No repository file or test is identified. Start by reproducing the ODBC workload with the forwarded localhost ports and with the MobyLinux IP, then compare the TCP behavior and available vpnkit diagnostics; done means isolating a reproducible vpnkit networking cause or documenting that the failure depends on the proprietary database or client.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker
- Domain
- networking, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100