In `connect` mode the client looping calling `connect` and `close` on a timer.
This could result in the server accepting the connection and the client accidentally
closing it immediately. This patch makes `tap-vsockd` keep trying to (re-)establish
the connection. Note that daemonization is delayed until after the first successful
negotiation, so attempts to send a packet afterwards should succeed.
Signed-off-by: David Scott <dave.scott@docker.com>
Our convention is to print command-line parse failures to the terminal
to allow easier interactive debugging, rather than sending them to
the syslog.
Signed-off-by: David Scott <dave.scott@docker.com>
We daemonize after checking the command-line and binding/connecting
the socket and creating the tap device. Only the ethernet frame
processing happens afterwards.
This patch also includes a new well-known service GUID for the
VPN-proxy ethernet service.
Signed-off-by: David Scott <dave.scott@docker.com>
Older versions of the Linux AF_HVSOCK can only accept() as they
don't allow connections to the parent partition. Support both
modes for now.
Signed-off-by: David Scott <dave.scott@docker.com>
The vmnet protocol expects to tell the client what the MAC address is.
This patch sets it on the TAP device.
Signed-off-by: David Scott <dave.scott@docker.com>
These packages will be shared by a number of utilities
so vendoring them in a shared place.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Previously the logs for a single connection would be something like:
2016/05/04 12:44:41 171 Accepted connection on fd 5 from 00000002.00010006
2016/05/04 12:44:41 171 Connected to docker &{{0xc82008a5b0}}
2016/05/04 12:44:44 171 copying from vsock to docker: 4465 bytes done
2016/05/04 12:44:44 171 copying from docker to vsock: 1324 bytes done
2016/05/04 12:44:44 171 Done. read: 4465 written: 1324
2016/05/04 12:44:44 171 Closing docker &{{0xc82008a5b0}}
2016/05/04 12:44:44 171 Closing vsock &{0xc820086840}
The "Connected" and "Closing" lines are not useful now that it is debugged and
working well. The "copying..." lines are redundant with the "Done" line. Reduce
to just:
2016/05/04 14:00:41 4 Accepted connection on fd 10 from 00000002.00010003
2016/05/04 14:00:41 4 Done. read: 90 written: 145
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Previously the proxy would listen only on the vsock port, which is
fine for accessing the port on the host, but if a container also wants
to access the port (e.g. via `--net=host` and using the Moby IP) then
we need to listen on the IP too.
Related to [docker/pinata#2854]
Signed-off-by: David Scott <dave.scott@docker.com>
- the initial length field should be the total length of the whole
frame including the variable length field and including the length
field
- when unmarshalling, return the number of bytes of payload actually
unmarshalled and not the size of the unmarshal buffer
Signed-off-by: David Scott <dave.scott@docker.com>
The 9P operations tell the host to connect to the vsock port in the
UDP case, so always listen before sending the 9P request.
Signed-off-by: David Scott <dave.scott@docker.com>
Since the header is variable length it's useful to write a length
field first, so the peer can read the rest of the packet as a block.
Signed-off-by: David Scott <dave.scott@docker.com>
A net.UDPListener is the datagram equivalent of a net.Conn. This patch
accepts at most one connection from vsock and attempts to read and write
UDP datagrams along it.
Signed-off-by: David Scott <dave.scott@docker.com>
This represents what is needed from the frontend side of the proxy:
- the ability to receive a UDP datagram and know who it is from
- the ability to send a UDP datagram to a particular destination
- the ability to close
Signed-off-by: David Scott <dave.scott@docker.com>
