libpcap
libpcap copied to clipboard
the-tcpdump-group
Add support for Realtek (Ethertype) DSA data
Realtek switchtag rtl4a (4 bytes long, protocol 0xA) and rtl8_4 (8 bytes long, protocol 0x04) are Ethertype DSA tags, inserted in the Ethernet header similar to an 802.1Q tag. Both shares the same Ethertype 0x8899 as other Realtek proprietary protocols.
Tested collecting traffic in a OpenWrt router and reading it in a wireshark with these extra https://github.com/luizluca/wireshark-dissectors.
There is no dissector for this protocol in tcpdump.
The doc about this tag was submitted to wikipedia https://en.wikipedia.org/wiki/Draft:Realtek_Layer_2_Protocols
It looks like this project's difficulty lies mostly in the documentation and specification aspects.
It looks like this project's difficulty lies mostly in the documentation and specification aspec
And wikipedia seems to be a no-go. They'll not accept an article with a raw description of a protocol. They need context, history, facts, not a table with descriptions.
Message ID: @.***>
That's a good policy, though sadly not entirely connected with their existing practice.
Anyway, the root of the problem is that the protocol designer has not published it completely, so whoever works on a decoder will face the dilemma of either doing a poor job, or publishing what was intended to be kept proprietary.
How much exactly is the encoding specified and in which documents?
I'd say at this point that documenting the DSA protocols is probably best done in some place such as the Linux kernel documentation, if Realtek isn't going to put anything about them in their datasheets.
I don't think documenting them is an requirement for this change. It might be a good idea, even if not a requirement, for changes to tcpdump (print-realtek.c) or Wireshark (upcoming packet-realtek.c) to dissect those protocols.
DSA protocols is probably best done in some place such as the Linux kernel documentation
We would need to start a new trend as there is no tag format described there. I only saw some tag doc in the header of each tag_*.c implementation.
I've just pushed an update that also adds the rtl8_4t tag format (net-next for 5.18). It is equals to rtl8_4 but positioned before the CRC. tcpdump does not bother the extra bytes after the payload and filters work as expected.
With wireshark, I'll assume by default the frame has a FCS and it will show part of the tag as a trailer and part of if as a failed frame sequence (although filters seem to work as expected). The user can disable the FCS warning changing the "Assuming packets have FCS" from "heuristic" to "never". This way, tag will be shown as a trailer.
So does this mean that the frames delivered to PF_PACKET sockets by the kernel for those DSA protocols will have no switch tag header, just an Ethernet packet?
So does this mean that the frames delivered to PF_PACKET sockets by the kernel for those DSA protocols will have no switch tag header, just an Ethernet packet?
I.e., the first 14 bytes of the packet are a 6-byte destination MAC address, a 6-byte source MAC address, and a 2-byte Ethernet tie value of 0x8899, with a tag switch at the beginning of the Ethernet payload, rather than one of the DSA formats with a switch tag inserted before, or in the middle of, the Ethernet header?
So does this mean that the frames delivered to
PF_PACKETsockets by the kernel for those DSA protocols will have no switch tag header, just an Ethernet packet?
For rtl8_4t, it will be a normal frame up to the end of the payload. The tag is added after it and before FCS (frame check sequence).
For the other tags (rtl4a and rtl8_4), the DSA tag is added as a proprietary Ethernet protocol. Although libpcap and other consumers might need to understand the realtek protocol to be able to parse anything in layer 3 or 4, the ethernet header is standard. It is still possible to filter using byte ranges, as ip header is just 4 or 8 bytes further in the frame.
There is no reason to treat realtek DSA tags as non-ethernet.
In my case, I implemented a wireshark parser in lua. However, the fact that libpcap captures those frames as raw really makes everything harder. I needed to manual edit the pcap file after I capture them.
There is no reason to treat realtek DSA tags as non-ethernet.
At least, no reason not to treat the DSA tagged frames with 0x8899 as non-Ethernet, as the Ethertype indicates that it has some Realtek protocol in it and the protocol can be determined from the header following the Ethernet header.
Marking rtl8_4t frames with a separate link-layer type would allow the dissector for that type to know for certain that there's a tag at the end of the frame, without needing to use any heuristics.