On 1/17/19 9:55 PM, Guy Harris wrote:
> On Jan 17, 2019, at 9:16 PM, Florian Fainelli <f.faine...@gmail.com> wrote:
>
>> On 1/17/2019 8:12 PM, Guy Harris wrote:
>>
>>> But if /sys/class/net/{device}/dsa doesn't exist in pre-4.19 kernels, how
>>> can you determine, from userland, whether a device is a DSA management-port
>>> NIC or not, in a system with a pre-4.19 kernel? If you can't determine
>>> that, you can't know whether to offer a list of DSA management-port tag
>>> type DLTs or not.
>>
>> *sigh* yes, you cannot determine what type of DSA tagging protocol is
>> applied on that interface in that case.
>
> There are two questions here:
>
> 1) Can you determine, in libpcap, what type of DSA tagging protocol is
> applied on an interface?
>
> 2) Can you determine, in libpcap, whether an interface is a regular
> Ethernet interface or an interface that has some type of DSA tagging
> protocol, whether you can determine *which* tagging protocol it is?
>
> If the answer to the first question is "yes", then
>
> 1) the answer to the second question is "yes"
>
> and
>
> 2) you can precisely determine *which* DLT value to use on the
> interface.
>
> If the answer to the first question is "no", but the answer to the second
> question is "yes", then
>
> 1) you can't precisely determine *which* DLT value to use on the
> interface
>
> *but*
>
> 2) you can offer the user who's doing the capture a choice of *all* the
> DLT values used for DSA tagging protocols and, if the *user* knows which
> tagging protocol is used - even if libpcap can't determine it - they can
> choose the appropriate DLT value, and programs reading the packets will be
> able to dissect the tags correctly.
>
> If the answer to *both* questions is "no", the best you could do would be to
> offer DLT_EN10MB, DLT_DOCSIS, *and* all the DLT values on *all* Ethernet
> interfaces, and let the user choose.
>
> In 4.19 and later, the answer to the first question, and thus to both
> questions, appears to be "yes".
>
> In pre-4.19 kernels, the answer to the first question appears to be "no";
> what's the answer to the second question?
>
> What's the answer to the first question in pre-4.19 kernels?
In pre-4.19 kernels there was really no way you could reliably tell a
DSA management interface apart from a regular Ethernet device in the
system, even by scanning the network device's relationship through
ifindex etc.
>
>> So either you have a new enough tcpdump/libpcap that supports pretty
>> printing one of these tag formats and you can somehow force the linktype
>> on the command line to get the decoding to work,
>
> In the second and third cases, "[forcing] the linktype on the command line"
> would be using the -y flag to set the link type to the appropriate link type
> for the DSA tag being used. That wouldn't be necessary with a 4.19 or later
> kernel - the appropriate link type would be chosen by libpcap.
Right
>
>> or everything is too
>> old and you just get what we currently have.
>>
>> Originally, I was considering an extension of the TPACKET_V3 format and
>> using reserved/unused fields there, but this was not a great fit,
>> because unlike VLAN tags, which can change on a packet per-packet basis,
>> the actual format of these switching tags is known at interface
>> setup/configuration time, and does not change. Here is what I had in
>> mind originally which is no longer relevant:
>>
>> https://github.com/ffainelli/linux/commits/dsa-tpacket
>
> The way you'd do that - which would work with *all* TPACKET formats as well
> as with non-memory-mapped capture - would be to:
>
> 1) get new ARPHRD_ types defined in the kernel for all the DSA tag
> types;
>
> 2) have the device advertise the appropriate new ARPHRD_ type, rather
> than ARPHRD_ETHER, based on the DSA tags in the packets;
>
> 3) have libpcap map those ARPHRD_ types to the corresponding DLT_
> values.
>
> That means changing the kernel - and the 4.19 kernel appears to *already*
> have a mechanism to determine the DSA tag type, which libpcap can use, so
> changing the kernel would be useful only if you can change pre-4.19 kernels.
Which is not possible none of that qualify as a bug fix we can ask
-stable maintainers to backport to < 4.19 kernel branches but that is
fine, there is a beginning to supporting those tags properly and it
starts with 4.19 and future tcpdump/libpcap/wireshark releases hopefully.
--
Florian
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
