On Mon, 2 Mar 2015 19:25:10 +
"Paul \"LeoNerd\" Evans" wrote:
> On Wed, 25 Feb 2015 10:20:40 +
> Denis Ovsienko 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 */
intsll_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
