Folks, I'm wondering if there has been any progress on this. Are there any thoughts on what Bill wrote in his email?
Thanks On Tue, Nov 13, 2012 at 2:41 PM, Ani Sinha <a...@aristanetworks.com> wrote: > Folks, > > I'm wondering if there has been any progress on this. Are there any thoughts > on what Bill wrote in his email? > > Thanks > ani > > > > On Fri, Nov 2, 2012 at 9:13 AM, Bill Fenner <fen...@gmail.com> wrote: >> >> On Wed, Oct 31, 2012 at 6:20 PM, Guy Harris <g...@alum.mit.edu> wrote: >> > >> > On Oct 31, 2012, at 2:50 PM, Ani Sinha <a...@aristanetworks.com> wrote: >> > >> >> pcap files that already have the tags reinsrted should work with >> >> current filter code. However for live traffic, one has to get the tags >> >> from CMSG() and then reinsert it back to the packet for the current >> >> filter to work. >> > >> > *Somebody* has to do that, at least to packets that pass the filter, >> > before they're handed to a libpcap-based application, for programs that >> > expect to see packets as they arrived from/were transmitted to the wire to >> > work. >> > >> > I.e., the tags *should* be reinserted by libpcap, and, as I understand >> > it, that's what the >> > >> > #if defined(HAVE_PACKET_AUXDATA) && >> > defined(HAVE_LINUX_TPACKET_AUXDATA_TP_VLAN_TCI) >> > ... >> > #endif >> > >> > blocks of code in pcap-linux.c in libpcap are doing. >> > >> > Now, if filtering is being done in the *kernel*, and the tags aren't >> > being reinserted by the kernel, then filter code stuffed into the kernel >> > would need to differ from filter code run in userland. There's already >> > precedent for that on Linux, with the "cooked mode" headers; those are >> > synthesized by libpcap from the metadata returned for PF_PACKET sockets, >> > and >> > the code that attempts to hand the kernel a filter goes through the filter >> > code, which was generated under the assumption that the packet begins with >> > a >> > "cooked mode" header, and modifies (a copy of) the code to, instead, use >> > the >> > special Linux-BPF-interpreter offsets to access the metadata. >> > >> > The right thing to do here would be to, if possible, do the same, so >> > that the kernel doesn't have to reinsert VLAN tags for packets that aren't >> > going to be handed to userland. >> >> In this case, it would be incredibly complicated to do this just >> postprocessing a set of bpf instructions. The problem is that when >> running the filter in the kernel, the IP header, etc. are not offset, >> so "off_macpl" and "off_linktype" would be zero, not 4, while >> generating the rest of the expression. We would also have to insert >> code when comparing the ethertype to 0x8100 to instead load the >> vlan-tagged metadata, so all jumps crossing that point would have to >> be adjusted, and if the "if-false" instruction was also testing the >> ethertype, then the ethertype would have to be reloaded (again >> inserting another instruction). >> >> Basically, take a look at the output of "tcpdump -d tcp port 22 or >> (vlan and tcp port 22)". Are the IPv4 tcp ports at x+14/x+16, or at >> x+18/x+20? If we're filtering in the kernel, they're at x+14/x+16 >> whether the packet is vlan tagged or not. If we're filtering on the >> actual packet contents (from a savefile, for example), they're at >> x+18/x+20 if the packet is vlan tagged. >> >> Also, an expression such as 'tcp port 22' would have to have some >> instructions added at the beginning, for "vlan-tagged == false", or it >> would match both tagged and untagged packets. >> >> This would be much more straightforward to deal with in the code >> generation phase, except until now the code generation phase hasn't >> known whether the filter is headed for the kernel or not. >> >> Bill > > _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
