On 2015-05-20 at 16:34:44 +0200, Vadim Kochan <[email protected]> wrote: > On Wed, May 20, 2015 at 04:30:30PM +0200, Tobias Klauser wrote: > > On 2015-05-13 at 11:54:01 +0200, Vadim Kochan <[email protected]> wrote: > > > On Wed, May 13, 2015 at 11:45:16AM +0200, Daniel Borkmann wrote: > > > > On 05/13/2015 11:31 AM, Vadim Kochan wrote: > > > > >On Wed, May 13, 2015 at 11:24:11AM +0200, Daniel Borkmann wrote: > > > > >>On 05/13/2015 11:21 AM, Vadim Kochan wrote: > > > > >>... > > > > >>>Or in case of Netlink link type enforce to use netsniff-ng pcap > > > > >>>format > > > > >>>... > > > > >> > > > > >>I think that would be rather unexpected as other tools like Wireshark > > > > >>cannot deal with that afaik. In that case, I rather prefer your patch > > > > >>here. > > > > > > > > > >Then the patch should be re-worked a little to use cooked header only > > > > >for default & nsec header formats, which I forgot to add in > > > > > > > > > > pcap_pkthdr_has_ll func ... > > > > > > > > > > > > > Ok, so changing defaults, I would like to avoid actually as it could > > > > potentially break things like Security Onion and others that rely on > > > Well currently Netlink capture pcap file is broken by default as it does > > > not make sense while identifying Netlink family protocol :-) > > > > > > > the current capturing format (if they use the default one). It would > > > > also make the pcaps bigger for that case. > > > > > > > > Here would be my suggestion on how to move forward: 1) add the cooked > > > > header which is understood by tcpdump/wireshark as a new pcap type, 2) > > > New magic number ? If yes then tcpdump/w-shark will not eat this .. > > > > > > > if we detect we're capturing on a netlink(/nlmon) device, use that as > > > In the patch I already check this ... > > > > Yes, from a quick look this seems ok. Could you please send an updated > > patch which also adds a short note to the netsniff-ng man page (section > > PCAP FORMATS) about the addition of the cooked header when capturing > > netlink traffic? > Sure. > > > > I'll then apply this as suggested and if there is any fallout we can > > deal with it in follow up patches. > > > > Thanks > > OK, but what about this ? > > I am not sure if I do correct conversion in a new added func > sockaddr_to_pcap_ll: > > pcap_ll->protocol = ___constant_swab16(sll->sll_protocol); > pcap_ll->hatype = ___constant_swab16(sll->sll_hatype); > pcap_ll->pkttype = ___constant_swab16(sll->sll_pkttype); > > I just see that netsniff-ng supports the swapped variant for such stuff, > so I just left the version which w-shark understood.
To be honest, I'm not completely sure. According to pcap(3) [1] the fields of the cooked header are in network byte order, so I'd suggest using htons() to make that intention clear (and make it work properly on big endian systems). Or did I get anything wrong? [1] http://linux.die.net/man/3/pcap -- You received this message because you are subscribed to the Google Groups "netsniff-ng" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
