Add support for mxl862xx-8021q Linux DSA tag

[pprindeville]

root@OpenWrt:~# tcpdump --version
tcpdump version 4.99.6
libpcap version 1.10.6 (64-bit time_t, with TPACKET_V3)
64-bit build, 64-bit time_t
root@OpenWrt:~# uname -a
Linux OpenWrt 6.18.21 #0 SMP Wed Apr 29 17:12:54 2026 aarch64
root@OpenWrt:~# cat /etc/os-release 
NAME="OpenWrt"
VERSION="SNAPSHOT"
ID="openwrt"
ID_LIKE="lede openwrt"
PRETTY_NAME="OpenWrt SNAPSHOT"
VERSION_ID="snapshot"
HOME_URL="https://openwrt.org/"
BUG_URL="https://bugs.openwrt.org/"
SUPPORT_URL="https://forum.openwrt.org/"
FIRMWARE_URL="https://downloads.openwrt.org/"
BUILD_ID="r0+34168-a202db9332"
OPENWRT_BOARD="mediatek/filogic"
OPENWRT_ARCH="aarch64_cortex-a53"
OPENWRT_TAINTS="no-all busybox"
OPENWRT_DEVICE_MANUFACTURER="OpenWrt"
OPENWRT_DEVICE_MANUFACTURER_URL="https://openwrt.org/"
OPENWRT_DEVICE_PRODUCT="Generic"
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="OpenWrt SNAPSHOT r0+34168-a202db9332"
OPENWRT_BUILD_DATE="1777482774"
root@OpenWrt:~# 

When I try to sniff packets on a DSA-attached port (conduit) I get:

tcpdump: listening on eth2, link-type DEBUG_ONLY (unstructured data for manual debugging only), snapshot length 1536 bytes
22:31:05.046525 UNSUPPORTED
        0x0000:  ffff ffff ffff 9a31 e62f b4d6 0806 0001  .......1./......
        0x0010:  0800 0604 0001 9a31 e62f b4d6 c0a8 03fa  .......1./......
        0x0020:  0000 0000 0000 c0a8 0301                 ..........

which is a raw IPv4 ARP packet.

• This is not a security issue (See first line).

[infrastation]

What does cat /sys/class/net/eth2/dsa/tagging output?

[guyharris]

What does cat /sys/class/net/eth2/dsa/tagging output?

For which read "there is not a single DSA link-layer protocol, the headers are dependent on the device, and may range from "no header" to various different flavors; the Linux capture mechanism support in libpcap checks the DSA type, which it reads from /sys/class/net/{interface name}/dsa/tagging, and specifies a link-layer type based on that". We'll probably need to add support for that particular DSA type.

If there is no special DSA header or trailer, as the packet dump suggests, we'll need to change it to use DLT_EN10MB (and change the comment before the table of DSA types not to say "Because a DSA-tagged frame is not a standard IEEE 802.3 Ethernet frame, the array elements must not use DLT_EN10MB.", because maybe sometimes the frame isn't DSA-tagged and it's a standard 802.3 Ethernet frame). If there is a trailer, we should implement a new DLT_ for the device, so that programs that want to look at the extra DSA information can do so, and update tcpdump to know about the new DLT_ value.

[infrastation]

The hex dump indeed represents an Ethernet packet without DSA prefix/infix/postfix, but it is essential to identify the link layer fully before jumping into conclusions. For example, Rx and Tx can use different encoding.

[pprindeville]

What does cat /sys/class/net/eth2/dsa/tagging output?

mxl862xx-8021q

[guyharris]

What does cat /sys/class/net/eth2/dsa/tagging output?

mxl862xx-8021q

https://lkml.org/lkml/2026/1/18/63

"This series adds very basic DSA support for the MaxLinear MxL86252
(5 PHY ports) and MxL86282 (8 PHY ports) switches.

MxL862xx integrates a firmware running on an embedded processor (running
Zephyr RTOS). Host interaction uses a simple netlink-like API transported
over MDIO/MMD.

This series includes only what's needed to pass traffic between user
ports and the CPU port: relayed MDIO to internal PHYs, basic port
enable/disable, and CPU-port special tagging.

Follow up series will bring bridge, VLAN, ... offloading, and support
for using a 802.1Q-based special tag instead of the proprietary 8-byte
tag."

(emphasis mine)

So I guess, with a DSA type of "mxl862xx-8021q", there is no special tag, and presumably the right thing to do is report that as DLT_EN10MB.

I'm not seeing any code in the tip-of-main-branch Linux kernel that would provide such a DSA type, unless I'm missing something. Are you running a kernel with additional changes from elsewhere, or was the 802.1q tag stuff present earlier but removed?

[infrastation]

The "802.1Q-based special tag" sounds like a proprietary n-byte infix tag rather than the standard 802.1Q, and the packet dump above does not use 802.1Q. This needs to be specified, for both Rx and Tx, before it can be implemented, and it would need packet captures for both Rx and Tx.

[infrastation]

For reference, the data sheets can be downloaded from:

• here for MxL86252C
• here for MxL86282C

In both cases the tag encoding is documented in Section 7.13.7.3 and the default EtherType is 0x88C3, which is the same as for GSW1xxx (see the-tcpdump-group/tcpdump-htdocs#51), but the tag encoding is different from GSW1xxx for the 6 bytes after EtherType and yes, different for Tx and Rx. The prose looks vague, but it seems in the "egress" direction (whichever it is) the tag can be either 6 or 8 bytes long (which also reminds of GSW1xxx), and in "ingress" direction (whichever it is) it is always 8 bytes long, also tagged and untagged frames can mix on an "egress" port. That's as far as the declared hardware capabilities go, and which subset the Linux driver uses is another factor. Whether the "802.1Q-based" encoding goes on top or replaces the encoding from the data sheet, the encoding that the Linux driver delivers must be set in stone and documented first, otherwise it is going be a wild goose chase.