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