Re: Requesting DLT_* values for Ethernet switches proprietary tagging protocol

[Florian Fainelli <f.fainelli () gmail com>]

On 1/17/19 9:55 PM, Guy Harris wrote:
> On Jan 17, 2019, at 9:16 PM, Florian Fainelli <f.fainelli () 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