On Mon, 2 Mar 2015 19:25:10 +0000 "Paul \"LeoNerd\" Evans" <leon...@leonerd.org.uk> wrote:
> On Wed, 25 Feb 2015 10:20:40 +0000 > Denis Ovsienko <de...@ovsienko.info> wrote: > > > This makes SLL2 quite close to sockaddr_ll (except the the order of > > fields and the sll_family field, which is told to be equal to > > AF_PACKET in this case). In other words, it looks sufficiently good > > on paper to proceed with the implementation. > > Ah; I wasn't intentionally making the order different to the > underlying address struct. Does that matter? I'm happy to amend it if > anyone thinks that's an issue, otherwise we'll just go with it. Actually, having had another look it seems to me the order does match the underlying struct type. I documented: +---------------------------+ | Protocol type | | (2 Octets) | +---------------------------+ | Interface index | | (4 Octets) | +---------------------------+ | ARPHRD_ type | | (2 Octets) | +---------------------------+ | Packet type | | (1 Octet) | +---------------------------+ | Link-layer address length | | (1 Octets) | +---------------------------+ | Link-layer address | | (8 Octets) | +---------------------------+ | Payload | . . . . . . whereas the struct is defined (at least to me in packet(7)) by: struct sockaddr_ll { unsigned short sll_family; /* Always AF_PACKET */ unsigned short sll_protocol; /* Physical layer protocol */ int sll_ifindex; /* Interface number */ unsigned short sll_hatype; /* ARP hardware type */ unsigned char sll_pkttype; /* Packet type */ unsigned char sll_halen; /* Length of address */ unsigned char sll_addr[8]; /* Physical layer address */ }; Are there any remaining objections to this idea? If not I would really appreciate it if it was approved and merged, as I believe it does bring useful features that tcpdump et.al. could easily make use of. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers