[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. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
