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

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

On 1/17/2019 8:12 PM, Guy Harris wrote:
> On Jan 17, 2019, at 7:49 PM, Florian Fainelli <f.fainelli () gmail com> wrote:
>
> > Le 1/17/19 à 6:29 PM, Guy Harris a écrit :
> > > On Jan 17, 2019, at 6:01 PM, Florian Fainelli <f.fainelli () gmail com> wrote:
> > >
> > > > Correct. The other ports are exposed as regular Ethernet network devices.
> > >
> > > OK, I've updated a comment in the pull request for that.
> > >
> > > So, in any pre-4.19 kernels, does the directory /sys/class/net/{device}/dsa exist even if there's no tagging file 
> > > in that directory?
> >
> > Neither the directory nor the file actually exist.
> >
> > > Or is there some other way, in pre-4.19 kernels, to determine if a NIC is a DSA management-port NIC?
> > >
> > > If so, then, even though you can't determine the tag type from userland, you could offer all the DLT_s for the 
> > > various tag types in the DLT list and let the user choose which one to use; they might be able to do so if they 
> > > know what type of device they're capturing on.  (If the tagging file *does* exist, you can just offer them the one 
> > > DLT_ that's correct for the device.)
> >
> > Good idea, people would certainly know which device they are capturing
> > on. Thanks!
>
> 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.

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, 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
-- 
Florian
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers