tcpdump mailing list archives
Re: Compile libpcap with DLT_LINUX_SLL2
From: Petr Vorel via tcpdump-workers <tcpdump-workers () lists tcpdump org>
Date: Wed, 13 May 2020 02:37:48 -0400 (EDT)
--- Begin Message --- From: Petr Vorel <petr.vorel () gmail com>
Date: Wed, 13 May 2020 08:39:44 +0200
Hi Guy,BTW, having just implemented SLL2 support in Wireshark, the layout of the header really doesn't work as well as I'd like with ARPHRD_NETLINK packets.I'd prefer something likestruct header { uint16_t hatype; /* link-layer address type */ uint8_t pkttype; /* packet type */ uint8_t halen; /* link-layer address length */ uint8_t addr[SLL_ADDRLEN]; /* link-layer address */ int32_t if_index; /* 1-based interface index */ uint16_t hatype_specific; /* dependent on sll3_hatype */ uint16_t protocol; /* protocol */ };because1) It puts the protocol field *after* the hatype field, and right before the payload, so that, for packets with an hatype of ARPHRD_NETLINK, we can treat everything up to the if_index field as the cooked-mode header, and have the dissector for ARPHRD_NETLINK-over-SLL treat the hatype_specific and protocol fields as fields for *it* to dissect. For that ARPHRD_ type, the protocol is a Netlink protocol type, so it really should be analyzed by the code that understands Netlink messages.2) It provides a field to handle various annoyances in the way that packets are provided to PF_PACKET sockets. In particular, Netlink messages are in the host byte order of the machine doing the capturing, so, for ARPHRD_NETLINK, we can have libpcap put the value 0x0123 in that field, in *host* byte order, so the code that processes the packets can just see whether that field's value is 0x0123 or 0x3210 and, based on that, determine whether the messages need to be byte-swapped. (Remember, somebody might capture Netlink traffic on a machine with one byte order but read the capture on a machine with the opposite byte order.)Is SLL2 sufficiently established that we'd have to introduce an SLL3 type, or can we just change SLL2 at this point?Thanks for the explanation. As I wrote at the ticket [1] I'd prefer to redefine LINKTYPE_LINUX_SLL2/DLT_LINUX_SLL2. Having LINKTYPE_LINUX_SLL3/DLT_LINUX_SLL3, when LINKTYPE_LINUX_SLL2/DLT_LINUX_SLL2 is not usable does not make much sense to me. Hope it wasn't used much as it wasn't the default. Kind regards, Petr [1] https://github.com/the-tcpdump-group/tcpdump-htdocs/pull/3
--- End Message ---
_______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- Re: Compile libpcap with DLT_LINUX_SLL2 Francois-Xavier Le Bail via tcpdump-workers (May 08)
- Message not available
- Re: Compile libpcap with DLT_LINUX_SLL2 Francois-Xavier Le Bail via tcpdump-workers (May 08)
- Re: Compile libpcap with DLT_LINUX_SLL2 Francois-Xavier Le Bail via tcpdump-workers (May 08)
- Re: Compile libpcap with DLT_LINUX_SLL2 Francois-Xavier Le Bail via tcpdump-workers (May 08)
- Message not available
- <Possible follow-ups>
- Re: Compile libpcap with DLT_LINUX_SLL2 Guy Harris via tcpdump-workers (May 08)
- Re: Compile libpcap with DLT_LINUX_SLL2 Guy Harris via tcpdump-workers (May 08)
- Re: Compile libpcap with DLT_LINUX_SLL2 Guy Harris via tcpdump-workers (May 08)
- Re: Compile libpcap with DLT_LINUX_SLL2 Bill Fenner via tcpdump-workers (May 09)
- Re: Compile libpcap with DLT_LINUX_SLL2 Guy Harris via tcpdump-workers (May 08)
- Re: Compile libpcap with DLT_LINUX_SLL2 Guy Harris via tcpdump-workers (May 09)
- Re: Compile libpcap with DLT_LINUX_SLL2 Francois-Xavier Le Bail via tcpdump-workers (May 10)
- Re: Compile libpcap with DLT_LINUX_SLL2 Francois-Xavier Le Bail via tcpdump-workers (May 10)
- Re: Compile libpcap with DLT_LINUX_SLL2 Francois-Xavier Le Bail via tcpdump-workers (May 10)
- Re: Compile libpcap with DLT_LINUX_SLL2 Petr Vorel via tcpdump-workers (May 12)