Re: LINUX_SLL2

["Paul \"LeoNerd\" Evans" <leonerd () leonerd org uk>]

On Mon, 2 Mar 2015 19:25:10 +0000
"Paul \"LeoNerd\" Evans" <leonerd () leonerd org uk> wrote:

> On Wed, 25 Feb 2015 10:20:40 +0000
> Denis Ovsienko <denis () 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

leonerd () 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