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>
The proxy process command-line arguments assume we're exposing TCP
or UDP ports on Moby's public IPs. Instead we're forwarding over vsock
where we must map the Moby ports onto vsock ports. Normally TCP and
UDP ports are different, but with vsock there is only one space of
port numbers so we have to map them into different ranges.
This patch maps Moby ports as follows:
- TCP port x onto vsock port 0x10000 + x
- UDP port x onto vsock port 0x20000 + x
Signed-off-by: David Scott <dave.scott@docker.com>
