On Wed, May 10, 2017 at 3:38 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > 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.
Ping? > > 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. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
