[tcpdump-workers] Requesting linktype for AF_VSOCK

Stefan Hajnoczi stefanha at gmail.com
Wed May 10 10:38:46 EDT 2017


[Resend - I sent the first version without being subscribed to the mailing list]

Hi,
Gerard Garcia previously requested a linktype for AF_VSOCK in July 2016
(http://seclists.org/tcpdump/2016/q3/17).  I am picking up his work now
that the vsockmon Linux kernel module has been merged upstream.  The
header files and struct definitions are available as part of the Linux
kernel headers.

AF_VSOCK is a guest<->host communications mechanism available in VMware
and KVM hypervisors.  It is not based on Ethernet or IP but offers
SOCK_STREAM and SOCK_DGRAM (only on VMware) semantics analogous to TCP
and UDP.

The vsockmon packet capture headers are here:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/vsockmon.h

The virtio-vsock transport headers are here:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/virtio_vsock.h

For your convenience I have included a full header description below
based on a draft previously posted by Guy Harris.

You can find more information about virtio-vsock and how to try it out
at http://qemu-project.org/Features/VirtioVsock.

Please assign a linktype for AF_VSOCK.

Thanks,
Stefan

---
Vsockmon packet structure

+---------------------------+
|         Source CID        |
|         (8 Octets)        |
+---------------------------+
|      Destination CID      |
|         (8 Octets)        |
+---------------------------+
|        Source port        |
|         (4 Octets)        |
+---------------------------+
|      Destination port     |
|         (4 Octets)        |
+---------------------------+
|         Operation         |
|         (2 Octets)        |
+---------------------------+
|    Transport header type  |
|         (2 Octets)        |
+---------------------------+
|   Transport header length |
|         (2 Octets)        |
+---------------------------+
|      Transport header     |
.                           .
.                           .
.                           .
+---------------------------+
|           Payload         |
.                           .
.                           .
.                           .


Description

The source and destination CID fields are in little-endian byte order;
they identify the source and destination vsock devices.

The source and destination port fields are in little-endian byte order;
they identify a connection or datagram flow between the source and
destination devices.

The operation field is in little-endian byte order; it contains a value
that is one of:

        * 1, for a connect operation;
        * 2, for a disconnect operation;
        * 3, for a control operation;
        * 4, for a data transfer operation.

The transport header type field is in little-endian byte order; it
contains a value that is one of:

        * 1, if there is no transport header information;
        * 2, if there is a virtio transport header.

The transport header length field is in little-endian byte order; it
indicates how many bytes of transport header follow the length field.
It may be non-zero even if the transport header type field has a value
of 1; in that case, the bytes for the transport header should be
skipped.

If the transport header type field has a value of 2, the transport
header is a virtio transport header as described below.  High-level
information about the packet is available in the vsockmon packet header
so parsing the transport header is only necessary for low-level packet
analysis.  This allows applications to process packet captures even when
the transport header type is unknown.

For packets with an operation field with a value of 4, the payload
follows the transport header.

Virtio transport header structure

+---------------------------+
|         Source CID        |
|         (8 Octets)        |
+---------------------------+
|      Destination CID      |
|         (8 Octets)        |
+---------------------------+
|        Source port        |
|         (4 Octets)        |
+---------------------------+
|      Destination port     |
|         (4 Octets)        |
+---------------------------+
|       Payload length      |
|         (4 Octets)        |
+---------------------------+
|        Socket type        |
|         (2 Octets)        |
+---------------------------+
|         Operation         |
|         (2 Octets)        |
+---------------------------+
|           Flags           |
|         (4 Octets)        |
+---------------------------+
|       Available Space     |
|         (4 Octets)        |
+---------------------------+
|       Receive Counter     |
|         (4 Octets)        |
+---------------------------+

Description

The source and destination CID fields are in little-endian byte order;
they identify the source and destination vsock devices.

The source and destination port fields are in little-endian byte order;
they identify a connection or datagram flow between the source and
destination devices.

The payload length field is in little-endian byte order; it indicates
how many bytes of data comprise the payload.

The socket type field is in little-endian byte order; it contains a
value that is one of:

        * 1, for a connection-oriented, in-order, reliable stream

The operation field is in little-endian byte order; it contains a value
that is one of:

        * 1, for a connection request
        * 2, for a connection response
        * 3, for a connection reset
        * 4, for a connection shutdown
        * 5, for a data packet
        * 6, for a credit update
        * 7, for a credit update request

The flags field is in little-endian byte order; its meaning depends on
the operation field value.  If the operation is a connection shutdown
then bit 0 indicates that no more data will be received and bit 1
indicates that no more data will be sent.

The available space field is in little-endian byte order; it indicates
how many bytes of payload data can be received without risk of dropping
packets.

The receive counter field is in little-endian byte order; it indicates
how many bytes of payload data have been received.


More information about the tcpdump-workers mailing list