Add gsw1xx mdio link support

[peteraxis]

This is adding the MaxLinear dsa switch protocol.

[guyharris]

See https://github.com/the-tcpdump-group/tcpdump/pull/1386/files#diff-c276d444d1c5601551f674be847ea7d74a040a33854247f4560418dd7bad3014 for a description of the header (in the big comment near the beginning of th file).

[infrastation]

I had a look in the current snapshot of Linux kernel source code and tried to comprehend a few messages on the net-next mailing list about gsw1xx DSA support patch series. My impression is that the latter is still being reviewed. Also I could not quickly identify the source code that implements the new DSA tag to relate it with the comments in the related tcpdump pull request, which I have also checked. Anyway, if the tag indeed is an 8-byte infix structure, it should not be difficult to support if things are done in the right order.

The change proposed in this pull request does three things:

• assigns a DLT value
• associates the not-yet-available DSA tag name with the DLT
• adds the new DLT to gen_linktype()

This pull request does not include any tests, but there is a test in the tcpdump pull request, which could be used for libpcap tests as well. Could you confirm the provided savefile exactly matches what the hardware communicates?

It would simplify the matter to have the DLT settled first. To support the DLT properly everywhere, it would be best to documented it in one place, not in every program that processes it. I suggest to move the DLT description from print-dsa-gsw1xx.c in tcpdump to a new page here (instructions) and to add references. Is there anything else besides the not-yet-merged patches that could support the DLT format?

As far as I can tell without running the code, the proposed change would not enable filtering in libpcap because it does not set any offsets for the new DLT. Getting the filtering right could be done after the DLT, it would not block the tcpdump changes.

Also, once all changes are in place in the kernel, libpcap and tcpdump, it would be nice to have everything tested at least one more time to make sure nothing went off in the process.

[mcr]

We are right now at a rock/hardspot for DLT allocation... neither our .h file, nor an IANA registry.
So, use our process, and Guy and I will fix the registry once it gets to AUTH48.

[peteraxis]

We are right now at a rock/hardspot for DLT allocation... neither our .h file, nor an IANA registry. So, use our process, and Guy and I will fix the registry once it gets to AUTH48.

It would be nice if you where little bit more helpful and specified what process and what header. IANA does not allocate ethertypes.

[guyharris]

It would be nice if you where little bit more helpful and specified what process

The process listed under "HOW TO ASSIGN A NEW VALUE" on the tcpdump.org link-layer type page.

(That's the page where we have historically listed LINKTYPE_/DLT_ link-layer type values.)

and what header.

Michael was probably referring to the pcap/dlt.h header - prior to that, they were in the pcap/bpf.h header.

However, those aren't the primary reference; the primary reference is currently the tcpdump.org link-layer type page listed above.

IANA does not allocate ethertypes.

LINKTYPE_/DLT_ values aren't EtherType values. They're values used in the file header of pcap files and in Interface Description Blocks in pcapng files to indicate the format of the first headers in packets.

The intent is to have an IANA registry for those values; there is currently an Internet-Draft for that.

[infrastation]

In other words, please focus on the documentation. After that's done right, we will assign the DLT, which will make it irrelevant which EtherType appears in the tag (even more so since EtherType is programmable).

[peteraxis]

On 11/21/25 13:03, Denis Ovsienko wrote: *infrastation* left a comment (the-tcpdump-group/libpcap#1578) <#1578 (comment)> In other words, please focus on the documentation. After that's done right, we will assign the DLT, which will make it irrelevant which EtherType appears in the tag (even more so since EtherType is programmable).

Tnx. I have started to see what I can do there.

…

— Reply to this email directly, view it on GitHub <#1578 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BMPILRQGMG4MWQ7UZNRJPCL3535PJAVCNFSM6AAAAACKYIKQWGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNRSG4ZDEMZWHA>. You are receiving this because you authored the thread.Message ID: ***@***.***>