[tcpdump-workers] protochain, BPF_JA, and sk_chk_filter
tcpdump produces bpf filter code for 'ip6 and protochain ipv6-frag' that
includes:
(000) ldh [12]
[...]
(021) ja 6
[...]
(062) ret #0
the jump instruction decodes to:
{ 0x5, 0, 0, 0xfff0 }
the linux kernel returns EINVAL when tcpdump tries to load this filter
code onto the socket:
Warning: Kernel filter failed: Invalid argument
further investigation shows that the failed check occurs in the linux
kernel's net/core/filter.c sk_chk_filter() function:
case BPF_JMP|BPF_JA:
/*
* Note, the large ftest->k might cause loops.
* Compare this with conditional jumps below,
* where offsets are limited. --ANK (981016)
*/
if (ftest->k >= (unsigned)(flen-pc-1))
return -EINVAL;
break;
(http://lxr.linux.no/linux+v2.6.26.5/net/core/filter.c#L409)
the comparison succeeds because the large unsigned k-value for this
instruction (0xfff0) is much larger than the number of remaining bpf
instructions (flen-pc-1).
is this a bug in libpcap's protochain filter generation code?
--
Robert Edmonds
[EMAIL PROTECTED]
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] protochain, BPF_JA, and sk_chk_filter
On 2008-09-18, Guy Harris <[EMAIL PROTECTED]> wrote: > > On Sep 17, 2008, at 2:26 PM, Robert Edmonds wrote: > >> the comparison succeeds because the large unsigned k-value for this >> instruction (0xfff0) is much larger than the number of remaining >> bpf >> instructions (flen-pc-1). > > It's so large, in fact, that its high-order bit is set - so, in > effect, it's a *negative* offset, making it a backwards branch. right, but the LSF filter validation code treats it as unsigned. > This means that protochain filters cannot be interpreted in any kernel- > based implementation of BPF I know of, as they all prohibit loops so > that you don't put a kernel thread into an infinite loop. i don't suppose the bpf compiler could be taught to generate separate kernel-only and userspace-only filter programs? -- Robert Edmonds [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] How to tell if application is handling packets
On 2009-12-26, Guy Harris wrote:
> and, yes, even with a package listed as version 0.8, the libpcap
> version might be something else - for some reason, Debian (and Ubuntu)
> call it "libpcap 0.8" even though they've upgraded to a later version
> of the library.
there is no "libpcap 0.8" package in debian. there is a libpcap0.8 version
0.9.8-5 package in debian stable and a libpcap0.8 version 1.0.0-6 package in
debian unstable. i.e., "libpcap0.8" is a package name, not a package name and
package version.
edmo...@chase{0}:~$ dpkg -l libpcap0.8
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name VersionDescription
+++-==-==-
ii libpcap0.8 1.0.0-6system interface for user-level
packet capture
edmo...@chase{0}:~$ dlocate libpcap.so
libpcap0.8-dbg: /usr/lib/debug/usr/lib/libpcap.so.1.0.0
libpcap0.8-dev: /usr/lib/libpcap.so
libpcap0.8: /usr/lib/libpcap.so.1.0.0
libpcap0.8: /usr/lib/libpcap.so.0.8
edmo...@chase{0}:~$ ls -l /usr/lib/libpcap.*
-rw-r--r-- 1 root root 342K Dec 12 12:05 /usr/lib/libpcap.a
lrwxrwxrwx 1 root root 14 Dec 15 19:55 /usr/lib/libpcap.so ->
libpcap.so.0.8
lrwxrwxrwx 1 root root 16 Dec 15 19:55 /usr/lib/libpcap.so.0.8 ->
libpcap.so.1.0.0
-rw-r--r-- 1 root root 195K Dec 12 12:05 /usr/lib/libpcap.so.1.0.0
edmo...@chase{0}:~$ objdump -p /usr/lib/libpcap.so.1.0.0 | grep SONAME
SONAME libpcap.so.0.8
edmo...@chase{0}:~$
debian binary shared library package names embed the SONAME version to allow
multiple major versions of a shared library to be simultaneously installed.
libpcap0.8 was added to the debian archive alongside libpcap0.7 in april
2004. from reviewing the libpcap0.8 changelog there has never been a
need to bump the SONAME since.
libpcap0.8 (0.9.3-1) unstable; urgency=low
* New upstream release: this is a new major version of libpcap but it is
API and ABI compatible with libpcap0.8 so the old soname and package
names were kept to avoid uncessary transition of all packages.
[...]
-- Romain Francoise Sat, 16 Jul 2005 14:14:20 +0200
--
Robert Edmonds
edmo...@debian.org
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] allow cooked mode on linux ethernet devices
hi, i'd like to be able to capture from an ethernet device on linux using the DLT_LINUX_SLL link type. i don't see any way to accomplish this using the existing API; libpcap really wants to give me a DLT_EN10MB handle. i submitted a patch to allow DLT_LINUX_SLL on ethernet devices a few months back: http://sourceforge.net/tracker/?func=detail&atid=469579&aid=3078313&group_id=53067 could someone please look at this and tell me if the patch needs more work or if it can be merged to mainline? thanks. -- Robert Edmonds edmo...@debian.org - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
