On Sun, Jun 14, 2015 at 01:22:25AM +0200, Daniel Borkmann wrote: > On 06/13/2015 02:30 PM, Vadim Kochan wrote: > >From: Vadim Kochan <[email protected]> > > > >Use Linux "cooked" header for Netlink interface automatically > >of as replavement of L2 header by specifiyng "--cooked" option. > > > > http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html > > > >"cooked" header makes sense to use for default or nsec pcap types > >which does not contain protocol info. > > > >Added new LINKTYPE_LINUX_SLL which indicates pcap file with > >Linux "cooked" header as L2 layer header.This pcap file is > >compatible with Wireshark's "cooked" header & vice-versa. > > > >Signed-off-by: Vadim Kochan <[email protected]> > > First, patch 3/3 looks okay. Will apply it once we have this > part resolved. > > Then, I've worked through this patch finally. I had it applied > locally to fix up some minor things (i.e. some places don't have > proper Linux kernel coding style, etc), but still have some > thoughts here: > > Anyway, what I don't yet like is that we need to tough every pcap Yeah, it looks ugly ...
> backend layer. I.e. the pcap i/o layer was designed in mind that > we could easily add other formats without having to touch mm/sg/rw > methods. Have you tested all of these with all corner cases? I was testing them earlier each kind of IO writer/reader. > > I.e. why not letting pcap_get_hdr_length() handle the additional > sll size in order to avoid putting upper layer logic into the > backend section (it should be decoupled from this, also for > performance reasons)? > > That also leaves me wondering, if it would be easier/possible to > add two internal/pseudp pcap magic types that just are pcap-us + sll > and pcap-ns + sll format, and since this number is unknown to others, > we'd need an automatic detection, that would remap the default to > the cooked type magics. Perhaps that could shrink the extra fast-path > logic we need to handle this (it would just need to have some extra > logic with the pcap file header itself, the rest might only be the > mapping of pkt-hdr, but no extra backend changes would be needed)? > > What do you think? I will try to rework this better. Regards, Vadim Kochan -- 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.
