Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
> > I do agree that instead of a /proc entry, we should check for a kenrel > > version >= X where X is the upstream version that first started > > supporting all the features needed by libpcap for vlan filtering. This > > is not a compile time check but a run time one. Does anyone see any > > issues with this? Is there any long term implications of this, like if > > you backport patches to an older long term supported kernel? Are there > > other better ways to do this, like may be returning feature bits from > > an ioctl call? This is something we need to deal with on a continuous > > basis as we keep supporting newer AUX fields and libpcap and other > > user land code needs to make use of it. At the same time, they need to > > handle backward compatibility issues with older kernels. > > As Eric mentioned earlier, for now there seems not to be a reliable > way to get to know which ops are present and which not. It's not > really nice, but if you want to make use of those new (ANC*) features, > probably checking kernel version might be the only way if I'm not > missing something. Now net-next is closed, but if it reopens, I'll > submit a version 2 of my patch where you've been CC'd to. If it gets > in, then at least it's for sure that since kernel this kind of > feature test is present. How are you going to tell whether a feature is present in a non-Linux kernel ? Testing kernel versions is somewhat suboptimal as support could be patched into a much older kernel (maybe not for this but ...) David ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
On Dec 17, 2012, at 1:50 AM, "David Laight" wrote: > How are you going to tell whether a feature is present in a non-Linux > kernel ? The Linux memory-mapped capture mechanism is not present in a non-Linux kernel, so all the libpcap work involved here would, if necessary on other platforms, have to be done differently on those platforms. Those platforms would have to have their own mechanisms to indicate whether any changes to filter code, processing of VLAN tags supplied out of band, etc. would need to be done. The same would apply to other additional features of the Linux memory-mapped capture mechanism that require changes in libpcap. (Ideally, those changes would only require changes in order to use them, and would not break existing userland code, including but not limited to libpcap - your reply was to Daniel Borkmann, who is, I believe, the originator of netsniff-ng: http://netsniff-ng.org which has its own code using PF_PACKET sockets.) ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
On Mon, Dec 17, 2012 at 11:35 AM, Guy Harris wrote: > On Dec 17, 2012, at 1:50 AM, "David Laight" wrote: > >> How are you going to tell whether a feature is present in a non-Linux >> kernel ? > > The Linux memory-mapped capture mechanism is not present in a non-Linux > kernel, so all the libpcap work involved here would, if necessary on other > platforms, have to be done differently on those platforms. Those platforms > would have to have their own mechanisms to indicate whether any changes to > filter code, processing of VLAN tags supplied out of band, etc. would need to > be done. > > The same would apply to other additional features of the Linux memory-mapped > capture mechanism that require changes in libpcap. Exactly. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
On Mon, Dec 17, 2012 at 2:35 AM, Guy Harris wrote: > > On Dec 17, 2012, at 1:50 AM, "David Laight" wrote: > >> How are you going to tell whether a feature is present in a non-Linux >> kernel ? > > The Linux memory-mapped capture mechanism is not present in a non-Linux > kernel, so all the libpcap work involved here would, if necessary on other > platforms, have to be done >differently on those platforms. Those platforms > would have to have their own mechanisms to indicate whether any changes to > filter code, processing of VLAN tags supplied out of >band, etc. would need > to be done. Actually lib-pcap has these pcap-.c files that are kind of like platform specific drivers that plug into platform independent code like gencode.c or bpf_filter.c. These platform specific drivers are responsible for getting packets from the kernel and running filters (kernel or userland) on it. So all linux specific code to get a packet and packet metadata from the kernel can neatly reside in pcap-linux.c. Unfortunately though, in this specific problem involving filtering with vlan tags, both code generation (gentags.c) and code running the filter (bpf_filter.c) will have to be aware of linux specific semantics. Due to the issues that Bill had explained earlier in the thread, we can not rely on post processing before installing the kernel filter. Therefore, we need to generate a filter that can be directly installed in the kernel. For the same reason, bpf_filter() code also needs to change - be aware of linux specific semantics. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
