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
