--- Begin Message ---
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 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?
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
