Re: Compile libpcap with DLT_LINUX_SLL2

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Sat, 9 May 2020 15:39:44 -0700
>
> 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 like
>
> struct 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 */
> };
>
> because
>
> 1) 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?
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers