Skip to content

Commit fad94e8

Browse files
dangowrtdangowrt
committed
libpcap: backport support for various DSA tags
Trying to tcpdump DSA conduits results in errors such as "unsupported DSA tag: mtk". Backport two commits adding support for various DSA tags to libpcap. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
1 parent 46c17c2 commit fad94e8

File tree

3 files changed

+351
-1
lines changed

3 files changed

+351
-1
lines changed

‎package/libs/libpcap/Makefile‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
99

1010
PKG_NAME:=libpcap
1111
PKG_VERSION:=1.10.5
12-
PKG_RELEASE:=1
12+
PKG_RELEASE:=2
1313

1414
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
1515
PKG_SOURCE_URL:=https://www.tcpdump.org/release/

‎package/libs/libpcap/patches/001-Add-support-for-Realtek-Ethertype-DSA-data.patch‎

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
From fcb2cbc3a306afcf7785a60a74dbea431e609d76 Mon Sep 17 00:00:00 2001
2+
From: Luiz Angelo Daros de Luca <luizluca@gmail.com>
3+
Date: Thu, 6 Jan 2022 15:51:54 -0300
4+
Subject: [PATCH 1/2] Add support for Realtek (Ethertype) DSA data
5+
6+
Realtek switchtag rtl4a (4 bytes long, protocol 0xA) and rtl8_4 (8 bytes
7+
long, protocol 0x04) are Ethertype DSA tags, inserted in the Ethernet
8+
header similar to an 802.1Q tag. Both shares the same Ethertype 0x8899
9+
as other Realtek proprietary protocols.
10+
11+
Realtek switchtag rtl8_4t is identical to rtl8_4 but positioned before
12+
the CRC, at the end of the Ethernet frame.
13+
---
14+
pcap-linux.c | 3 +++
15+
1 file changed, 3 insertions(+)
16+
17+
--- a/pcap-linux.c
18+
+++ b/pcap-linux.c
19+
@@ -5281,6 +5281,9 @@ static struct dsa_proto {
20+
{ "brcm-prepend", DLT_DSA_TAG_BRCM_PREPEND },
21+
{ "dsa", DLT_DSA_TAG_DSA },
22+
{ "edsa", DLT_DSA_TAG_EDSA },
23+
+ { "rtl4a", DLT_EN10MB },
24+
+ { "rtl8_4", DLT_EN10MB },
25+
+ { "rtl8_4t", DLT_EN10MB },
26+
};
27+
28+
static int

‎package/libs/libpcap/patches/002-Linux-handle-other-DSA-tags.patch‎

Lines changed: 322 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,322 @@
1+
From 7d298976beff0cce310fb53a430f82b53f43a394 Mon Sep 17 00:00:00 2001
2+
From: Guy Harris <gharris@sonic.net>
3+
Date: Fri, 14 Feb 2025 19:12:24 -0800
4+
Subject: [PATCH 2/2] Linux: handle other DSA tags.
5+
6+
Many of those entries need their own LINKTYPE_/DLT_? values, including
7+
tcpdump and Wireshark support for same, but at least this lets you see
8+
raw hex data from a capture.
9+
10+
Fixes #1367.
11+
12+
Supercedes #1451.
13+
---
14+
pcap-linux.c | 284 ++++++++++++++++++++++++++++++++++++++++++++++++++-
15+
1 file changed, 280 insertions(+), 4 deletions(-)
16+
17+
--- a/pcap-linux.c
18+
+++ b/pcap-linux.c
19+
@@ -5267,23 +5267,299 @@ iface_get_offload(pcap_t *handle _U_)
20+
}
21+
#endif /* SIOCETHTOOL */
22+
23+
+/*
24+
+ * As per
25+
+ *
26+
+ * https://www.kernel.org/doc/html/latest/networking/dsa/dsa.html#switch-tagging-protocols
27+
+ *
28+
+ * Type 1 means that the tag is prepended to the Ethernet packet.
29+
+ * LINKTYPE_ETHERNET/DLT_EN10MB doesn't work, as it would try to
30+
+ * dissect the tag data as the Ethernet header. These should get
31+
+ * their own LINKTYPE_DLT_ values.
32+
+ *
33+
+ * Type 2 means that the tag is inserted into the Ethernet header
34+
+ * after the source address and before the type/length field.
35+
+ *
36+
+ * Type 3 means that tag is a packet trailer. LINKTYPE_ETHERNET/DLT_EN10MB
37+
+ * works, unless the next-layer protocol has no length field of its own,
38+
+ * so that the tag might be treated as part of the payload. These should
39+
+ * get their own LINKTYPE_/DLT_ values.
40+
+ *
41+
+ * If you get an "unsupported DSA tag" error, please add the tag to here,
42+
+ * complete with a full comment indicating whether it's type 1, 2, or 3,
43+
+ * and, for type 2, indicating whether it has an Ethertype and, if so
44+
+ * what that type is, and whether it's registered with the IEEE or is
45+
+ * self-assigned. Also, point to *something* that indicates the format
46+
+ * of the tag.
47+
+ */
48+
static struct dsa_proto {
49+
const char *name;
50+
bpf_u_int32 linktype;
51+
} dsa_protos[] = {
52+
/*
53+
- * None is special and indicates that the interface does not have
54+
- * any tagging protocol configured, and is therefore a standard
55+
- * Ethernet interface.
56+
+ * Type 1. See
57+
+ *
58+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_ar9331.c
59+
+ */
60+
+ { "ar9331", DLT_EN10MB },
61+
+
62+
+ /*
63+
+ * Type 2, without an Ethertype at the beginning,
64+
+ * assigned a LINKTYPE_/DLT_ value.
65+
*/
66+
- { "none", DLT_EN10MB },
67+
{ "brcm", DLT_DSA_TAG_BRCM },
68+
+
69+
+ /*
70+
+ * Type 2, with Ethertype 0x8874, assigned to Broadcom.
71+
+ *
72+
+ * This doies not require a LINKTYPE_/DLT_ value, it
73+
+ * just requires that Ethertype 0x8874 be dissected
74+
+ * properly.
75+
+ */
76+
+ { "brcm-legacy", DLT_EN10MB },
77+
+
78+
+ /*
79+
+ * Type 1.
80+
+ */
81+
{ "brcm-prepend", DLT_DSA_TAG_BRCM_PREPEND },
82+
+
83+
+ /*
84+
+ * Type 2, without an Etherype at he beginning,
85+
+ * assigned a LINKTYPE_/DLT_ value.
86+
+ */
87+
{ "dsa", DLT_DSA_TAG_DSA },
88+
+
89+
+ /*
90+
+ * Type 2, with an Ethertype field, but without
91+
+ * an assigned Ethertype value that can be relied
92+
+ * on; assigned a LINKTYPE_/DLT_ value.
93+
+ */
94+
{ "edsa", DLT_DSA_TAG_EDSA },
95+
+
96+
+ /*
97+
+ * Type 1, with different transmit and receive headers,
98+
+ * so can't really be handled well with the current
99+
+ * libpcap API and with pcap files. Use DLT_LINUX_SLL,
100+
+ * to get the direction?
101+
+ *
102+
+ * See
103+
+ *
104+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_gswip.c
105+
+ */
106+
+ { "gswip", DLT_EN10MB },
107+
+
108+
+ /*
109+
+ * Type 3. See
110+
+ *
111+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_hellcreek.c
112+
+ */
113+
+ { "hellcreek", DLT_EN10MB },
114+
+
115+
+ /*
116+
+ * Type 3, with different transmit and receive headers,
117+
+ * so can't really be handled well with the current
118+
+ * libpcap API and with pcap files. Use DLT_LINUX_SLL,
119+
+ * to get the direction?
120+
+ *
121+
+ * See
122+
+ *
123+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_ksz.c#L102
124+
+ */
125+
+ { "ksz8795", DLT_EN10MB },
126+
+
127+
+ /*
128+
+ * Type 3, with different transmit and receive headers,
129+
+ * so can't really be handled well with the current
130+
+ * libpcap API and with pcap files. Use DLT_LINUX_SLL,
131+
+ * to get the direction?
132+
+ *
133+
+ * See
134+
+ *
135+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_ksz.c#L160
136+
+ */
137+
+ { "ksz9477", DLT_EN10MB },
138+
+
139+
+ /*
140+
+ * Type 3, with different transmit and receive headers,
141+
+ * so can't really be handled well with the current
142+
+ * libpcap API and with pcap files. Use DLT_LINUX_SLL,
143+
+ * to get the direction?
144+
+ *
145+
+ * See
146+
+ *
147+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_ksz.c#L341
148+
+ */
149+
+ { "ksz9893", DLT_EN10MB },
150+
+
151+
+ /*
152+
+ * Type 3, with different transmit and receive headers,
153+
+ * so can't really be handled well with the current
154+
+ * libpcap API and with pcap files. Use DLT_LINUX_SLL,
155+
+ * to get the direction?
156+
+ *
157+
+ * See
158+
+ *
159+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_ksz.c#L386
160+
+ */
161+
+ { "lan937x", DLT_EN10MB },
162+
+
163+
+ /*
164+
+ * Type 2, with Ethertype 0x8100; the VID can be interpreted
165+
+ * as per
166+
+ *
167+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_lan9303.c#L24
168+
+ *
169+
+ * so giving its own LINKTYPE_/DLT_ value would allow a
170+
+ * dissector to do so.
171+
+ */
172+
+ { "lan9303", DLT_EN10MB },
173+
+
174+
+ /*
175+
+ * Type 2, without an Etherype at he beginning,
176+
+ * should be assigned a LINKTYPE_/DLT_ value.
177+
+ *
178+
+ * See
179+
+ *
180+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_mtk.c#L15
181+
+ */
182+
+ { "mtk", DLT_EN10MB },
183+
+
184+
+ /*
185+
+ * None is special and indicates that the interface does not have
186+
+ * any tagging protocol configured, and is therefore a standard
187+
+ * Ethernet interface.
188+
+ */
189+
+ { "none", DLT_EN10MB },
190+
+
191+
+ /*
192+
+ * Type 1.
193+
+ *
194+
+ * See
195+
+ *
196+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_ocelot.c
197+
+ */
198+
+ { "ocelot", DLT_EN10MB },
199+
+
200+
+ /*
201+
+ * Type 1.
202+
+ *
203+
+ * See
204+
+ *
205+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_ocelot.c
206+
+ */
207+
+ { "seville", DLT_EN10MB },
208+
+
209+
+ /*
210+
+ * Type 2, with Ethertype 0x8100; the VID can be interpreted
211+
+ * as per
212+
+ *
213+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_8021q.c#L15
214+
+ *
215+
+ * so giving its own LINKTYPE_/DLT_ value would allow a
216+
+ * dissector to do so.
217+
+ */
218+
+ { "ocelot-8021q", DLT_EN10MB },
219+
+
220+
+ /*
221+
+ * Type 2, without an Etherype at he beginning,
222+
+ * should be assigned a LINKTYPE_/DLT_ value.
223+
+ *
224+
+ * See
225+
+ *
226+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_qca.c
227+
+ */
228+
+ { "qca", DLT_EN10MB },
229+
+
230+
+ /*
231+
+ * Type 2, with Ethertype 0x8899, assigned to Realtek;
232+
+ * they use it for several on-the-Ethernet protocols
233+
+ * as well, but there are fields that allow the two
234+
+ * tag formats, and all the protocols in question,
235+
+ * to be distinguiished from one another.
236+
+ *
237+
+ * This doies not require a LINKTYPE_/DLT_ value, it
238+
+ * just requires that Ethertype 0x8899 be dissected
239+
+ * properly.
240+
+ *
241+
+ * See
242+
+ *
243+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_rtl4_a.c
244+
+ *
245+
+ * http://realtek.info/pdf/rtl8306sd%28m%29_datasheet_1.1.pdf
246+
+ *
247+
+ * and various pages in tcpdump's print-realtek.c and Wireshark's
248+
+ * epan/dissectors/packet-realtek.c for the other protocols.
249+
+ */
250+
{ "rtl4a", DLT_EN10MB },
251+
+
252+
+ /*
253+
+ * Type 2, with Ethertype 0x8899, assigned to Realtek;
254+
+ * see above.
255+
+ */
256+
{ "rtl8_4", DLT_EN10MB },
257+
+
258+
+ /*
259+
+ * Type 3, with the same tag format as rtl8_4.
260+
+ */
261+
{ "rtl8_4t", DLT_EN10MB },
262+
+
263+
+ /*
264+
+ * Type 2, with Ethertype 0xe001; that's probably
265+
+ * self-assigned, so this really should ahve its
266+
+ * own LINKTYPE_/DLT_ value.
267+
+ *
268+
+ * See
269+
+ *
270+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_rzn1_a5psw.c
271+
+ */
272+
+ { "a5psw", DLT_EN10MB },
273+
+
274+
+ /*
275+
+ * Type 2, with Ethertype 0x8100 or the self-assigned
276+
+ * 0xdadb, so this really should ahve its own
277+
+ * LINKTYPE_/DLT_ value; that would also allow the
278+
+ * VID of the tag to be dissected as per
279+
+ *
280+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_8021q.c#L15
281+
+ */
282+
+ { "sja1105", DLT_EN10MB },
283+
+
284+
+ /*
285+
+ * Type "none of the above", with both a header and trailer,
286+
+ * with different transmit and receive tags. Has
287+
+ * Ethertype 0xdadc, which is probably self-assigned.
288+
+ * This should really have its own LINKTYPE_/DLT_ value.
289+
+ */
290+
+ { "sja1110", DLT_EN10MB },
291+
+
292+
+ /*
293+
+ * Type 3, as the name suggests.
294+
+ *
295+
+ * See
296+
+ *
297+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_trailer.c
298+
+ */
299+
+ { "trailer", DLT_EN10MB },
300+
+
301+
+ /*
302+
+ * Type 2, with Ethertype 0x8100; the VID can be interpreted
303+
+ * as per
304+
+ *
305+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_8021q.c#L15
306+
+ *
307+
+ * so giving its own LINKTYPE_/DLT_ value would allow a
308+
+ * dissector to do so.
309+
+ */
310+
+ { "vsc73xx-8021q", DLT_EN10MB },
311+
+
312+
+ /*
313+
+ * Type 3.
314+
+ *
315+
+ * See
316+
+ *
317+
+ * https://elixir.bootlin.com/linux/v6.13.2/source/net/dsa/tag_xrs700x.c
318+
+ */
319+
+ { "xrs700x", DLT_EN10MB },
320+
};
321+
322+
static int

0 commit comments

Comments
 (0)