No practical change, but adds the "cherry-picked from" to aid tracking. This
has also been queued for stable so will eventually show up in a 4.4.x and can
be dropped from here.
Signed-off-by: Ian Campbell <ian.campbell@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>
We are now using a custom kernel not unmodified upstream, so
best to identify it.
Also fix https://github.com/docker/pinata/issues/2153
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This is simpler, and as a by-product should resolve
https://github.com/docker/pinata/issues/1968
as it uses the now-more-correct loop device names
that newer util-linux expects.
Signed-off-by: Justin Cormack <justin.cormack@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>
Using 23a432c2-537a-4291-bcb5-d62504644739 as the GUID (randomly generated).
The Windows host side will uses this as service ID, once written.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
