Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

2018-07-11 Thread Guy Harris
Note, by the way, that, for memory-mapped captures, the Linux kernel appears, in tpacket_rcv(), to reserve 16 octets of extra space, which is exactly enough to insert a DLT_LINUX_SLL header, but not enough for a DLT_LINUX_SLL2 header (and wouldn't even be enough if we *didn't* pad it to put the

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

2018-07-11 Thread Guy Harris
On Jul 11, 2018, at 1:14 PM, Denis Ovsienko wrote: > Could the 4-octet field (ifindex) be at the beginning? Yes, but the padding would still be necessary. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

2018-07-11 Thread Denis Ovsienko
On Wed, 11 Jul 2018 19:41:06 +0100 Guy Harris wrote > Currently > > https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html > > has a 2-octet field followed immediately by a 4-octet field. > > This means the 4-octet field isn't aligned on a 4-octet boundary;

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

2018-07-11 Thread Guy Harris
Currently https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html has a 2-octet field followed immediately by a 4-octet field. This means the 4-octet field isn't aligned on a 4-octet boundary; I'm going to update the LINKTYPE_LINUX_SLL2 specification to put a 2-byte reserved field

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

2018-07-11 Thread Guy Harris
On Jul 11, 2018, at 7:06 AM, Petr Vorel wrote: > It looks like 1) is impossible the need for both to define > pcap_create_interface(). Currently, the list isn't set in pcap_create(), it's set in pcap_activate(), so it'd be set in pcap_activate_linux(). You would then either 1) have

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

2018-07-11 Thread Petr Vorel
Hi, > > 1) Keeping LINKTYPE_LINUX_SLL [2] altogether with LINKTYPE_LINUX_SLL2, > > compile > > both (having one of them as default for linux, second allow to use with -y > > switch > > in tcpdump). > > 2) Keeping LINKTYPE_LINUX_SLL [2] altogether with LINKTYPE_LINUX_SLL2 but > > compile only

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

2018-07-11 Thread Denis Ovsienko
> [1] https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html > [2] https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html > [3] https://github.com/the-tcpdump-group/libpcap/issues/127 JFYI, I remember the beginning of this story from January 2015 well. Paul Evans suggested the

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

2018-07-11 Thread Petr Vorel
Hi, > > This requires a numerical value to be assigned to LINKTYPE_LINUX_SLL2 and > > DLT_LINUX_SLL2; no such value has yet been assigned. > It seems it should be 276 (next free number). > I've sent it as a pull request to github (I prefer using git format-patch && > git > send-email to ML as

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

2018-07-11 Thread Petr Vorel
Hi Guy, > (Re-sending, from my real e-mail address rather than my forwarding-for-life > e-mail address, because the latter had issues and required moderation.) I had some issues with not appearing messages as well :(. > On Jul 10, 2018, at 9:34 AM, Petr Vorel wrote: > > I'm playing with

Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)

2018-07-10 Thread Guy Harris
(Re-sending, from my real e-mail address rather than my forwarding-for-life e-mail address, because the latter had issues and required moderation.) On Jul 10, 2018, at 9:34 AM, Petr Vorel wrote: > I'm playing with implementing LINKTYPE_LINUX_SLL2 [1] as a part of [3] > in libpcap and using it