[tcpdump-workers] Request DLT_/LINKTYPE_ value for vSockets
vSockets are used for host<>guest communication using the standard socket API. They already supported in the mainline Linux kernel and can be used in VMware VMs. There is an ongoing work to implement a virtio transport which will add vSockets support to QEMU. Additionally, it will include a vsockmon device that will allow the host to monitor the data exchanged through vSockets. The vsockmon device has already been reviewed and its header is already defined: http://marc.info/?l=linux-netdev&m=146661193816961&w=2 https://github.com/GerardGarcia/linux/blob/vsockmon/include/uapi/linux/vsockmon.h We have also implemented a tcpdump printer and a wireshark dissector which are being reviewed. We would like to request a DLT_VSOCK/LINKTYPE_VSOCK identifier to finish the tcpdump and wireshark patches. Thanks, Gerard ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request DLT_/LINKTYPE_ value for vSockets
On 07/18/2016 11:36 PM, Guy Harris wrote:
OK, so here's a description of the header, in the style of other pages linked to by the
"Link-layer header types" page:
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 XXX.
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:
{fill in description here}
For packets with an operation field with a value of 4, the payload follows the
transport header.
So the questions that remain are:
1) What do the ports identify? Different connections on the same vsock
device?
They identify a data stream within a vsock device.
2) What is the format of the transport header?
It is well described in the virtio vsock specification:
https://stefanha.github.io/virtio/#x1-287 May we just link there?
At some point it will be merged with the official specification
documents
(http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html) so the
link will need to be updated.
3) Will the length of the transport header ever change?
We should assume that it may change.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request DLT_/LINKTYPE_ value for vSockets
On 07/19/2016 08:56 PM, Guy Harris wrote:
On Jul 19, 2016, at 7:12 AM, Gerard Garcia wrote:
2) What is the format of the transport header?
It is well described in the virtio vsock specification:
https://stefanha.github.io/virtio/#x1-287 May we just link there?
If that's
struct virtio_vsock_hdr {
le64 src_cid;
le64 dst_cid;
le32 src_port;
le32 dst_port;
le32 len;
le16 type;
le16 op;
le32 flags;
le32 buf_alloc;
le32 fwd_cnt;
};
that appears to duplicate fields in the link-layer header; are those fields, in
fact, duplicates?
Yes, the source/destination cid/port are duplicates. The vsockmon header
always includes these fields in case there is no transport header
attached or if that information is not included.
The other fields are different.
3) Will the length of the transport header ever change?
We should assume that it may change.
So will the transport header ever change *without* the length changing? If it
changes by adding new data to the end, or by removing some fields at the end,
code that parses a packet in a capture can use the length field to determine
whether the added fields are present, but if the header can change without the
length changing - or by more than just fields being added to the end or removed
from the end - there needs to be something in the header to give a version for
the transport header, such as changing the transport header type.
No, it will never change without changing the length field. This is the
purpose of this field, being able to grow the transport header if it is
necessary without worrying of breaking existing parsers.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
