DSA is not Ethernet

[infrastation]

No description provided.

[infrastation]

In my working copy inbound and outbound seem to work as expected on a live DLT_LINUX_DSA_UNKNOWN capture, which seems to mean DSA frame direction can be extracted using SKF_AD_PKTTYPE even without using the cooked mode. This needs a bit more attention.

[guyharris]

In my working copy inbound and outbound seem to work as expected on a live DLT_LINUX_DSA_UNKNOWN capture, which seems to mean DSA frame direction can be extracted using SKF_AD_PKTTYPE even without using the cooked mode. This needs a bit more attention.

The packet direction from SKF_AD_PKTTYPE reflects whether the packet is sent by the networking stack or received by the networking stack and, if it's received by the networking stack, how was it received - sent to the host, broadcast, multicast, or sent to some other host (presumably received due to the adapter being in promiscuous mode).

In kernel-mode filtering, that has to be done by testing the special packet offset, as it's not part of the skbuff data. It's also supported in user-mode filter when capturing on Linux, as pcapint_filter_with_aux_data() is used, and it's passed a pointer to the auxiliary data.

That information is put into the packet data only in cooked mode, so it doesn't appear in non-LINKTYPE_LINUX_SLL/LINKTYPE_LINUX_SLL2 captures. That means that inbound and outbound won't work on non-cooked captures.

Full support of pcapng would allow saving metadata in the capture file, and thus would allow inbound and outbound to work on pcapng packets that include the metadata.

Whether direction information in the DSA headers agrees with direction information from the Linux networking stack is another matter.

[infrastation]

Let me debug this a bit more to understand what exactly works and what does not.

[infrastation]

Having considered these comments for a while, I understand these reasons also explain #1482. In this case on Linux for the specific case of DSA the kernel's idea of the frame direction will never be available in userspace because the capture must not use cooked mode to preserve the headers. Ironically, it is possible to tell the kernel to filter the frames based on its idea of the direction, but it is impossible to know directly what it is.

On the one hand, this means there would be no immediate gain in introducing another DLT, something such as DLT_DEBUG_RAW_DATA, and using that for DSA now until it is clear how to implement DLT_LINUX_DSA_UNKNOWN later with a direction, because there would be no direction.

On the other hand, there may be a good reason to define the Linux unknown DSA DLT with other useful metadata, such as the interface name (or index) and the DSA tag name (or number from linux/include/net/dsa.h), or something else that would be very useful later, but does not immediately come to mind; also the DLT_DEBUG_RAW_DATA could be used for non-DSA use cases with similar requirements.

Given no other input, I am going to change this into a generic non-DSA non-Linux DLT and to merge these changes soon to enable back-porting to libpcap-1.10.

This looks very similar to the problem that DLT_DOCSIS on Ethernet interfaces intended to solve.

[guyharris]

In this case on Linux for the specific case of DSA the kernel's idea of the frame direction will never be available in userspace because the capture must not use cooked mode to preserve the headers.

...

...until it is clear how to implement DLT_LINUX_DSA_UNKNOWN later with a direction, because there would be no direction.

The DLT_LINUX_SLL/DLT_LINUX_SLL2 header is constructed by pcap_handle_packet_mmap() in pcap-linux.c from the metadata provided by the kernel; if DLT_LINUX_DSA_UNKNOWN were to contain a direction metadata header, that could be done in the same fashion. If the prepended header would be longer than 16 bytes, the code in create_ring() that increases tp_reserve would have to reserve additional space.

[infrastation]

Thank you for explaining that, but I can neither prove this theory wrong nor implement it in code safely in a timely manner. This revision introduces and uses a very generic DLT_DEBUG_ONLY. This should be sufficient to unblock libpcap 1.10.x releases now and this does not prevent designing a DLT that would be better suited for unsupported DSA tags on Linux. This is going to be merged by the end of this week.