Re: TCPDUMP 3.9.4 under Fedora Core 5 seems to generate the wrong BPF for DLT_PRISM_HEADER.

["Bruce Keats" <brucekeats () gmail com>]

After digging into the issue, I have come up with a patch.  The crux of the
problem is that the off_ll is added twice when generating the BPF code that
peeks into the LLC header.  The patch I came up with adjusts the offset when
generating the cmp instructions.  I believe the same problem exists for
DLT_IEEE802_11_RADIO_AVS, but I don't have a card that generates this data,
so I am unable to test my theory.  Maybe someone else out there can check
DLT_IEEE802_11_RADIO_AVS.

For all the cases I have tested, the patch appears to resolve the issue
without causing other problems.

In my opinion, the patch could be better, but I don't have time to spent on
it.  There seems to be a lot of paths through the code that end up calling
gen_cmp().  Someone else who knows the code better than I might be able to
come up with a better fix.

The patch is attached as a file.

Bruce

On 8/29/06, Bruce Keats <brucekeats () gmail com> wrote:
>  Hi,
>
> I am running FC5 which comes with tcpdump 3.9.4 and libpcap 0.9.4 and I am
> having problems filtering 802.11 packets.  When I look at the code
> generated for a wifi card that has the Atheros chip set and supports
> DLT_PRISM_HEADER, the offset to the IP header looks off.
>
> [root@dhcp43 ~]# tcpdump -L -i athm0
> Data link types (use option -y to set):
>   PRISM_HEADER (802.11 plus Prism header)
>
>
> [root@dhcp43 ~]# tcpdump -i athm0 -s0 -d ip
> tcpdump: WARNING: athm0: no IPv4 address assigned
> (000) ldh      [318]
> (001) jeq      #0x800           jt 2    jf 3
> (002) ret      #65535
> (003) ret      #0
> [root@dhcp43 ~]#
>
>
> If I read this code correctly, it is loading a 2 byte half word at offset
> 318 (0x13e) then doing a compare against the value 0x800 for a match.  The
> offset is wrong because the PRISM header is 144 bytes long, 24 bytes for a
> 801.11 data frame and 8 bytes for the LLC frame for which the last 2 bytes
> indicate IP (offset should be 174).
>
> If I try something like trying to find the TCP header, the generated code
> also seems suspect:
>
> [root@dhcp43 ~]# tcpdump -i athm0 -s0 -d tcp
> tcpdump: WARNING: athm0: no IPv4 address assigned
> (000) ldh      [318]
> (001) jeq      #0x86dd          jt 2    jf 4
> (002) ldb      [182]
> (003) jeq      #0x6             jt 7    jf 8
> (004) jeq      #0x800           jt 5    jf 8
> (005) ldb      [185]
> (006) jeq      #0x6             jt 7    jf 8
> (007) ret      #65535
> (008) ret      #0
> [root@dhcp43 ~]#
>
> The magic number 318 is 174+144 or "the offset to find the LLC protocol"
> plus "the PRISM header length".
>
> I did some google searches and I didn't come accross anything.  I checked
> the TCPDUMP workers list and I didn't see anything, but it appears the
> archives might be broken on tcpdump.org and gmane.org doesn't seem to go
> back very far.
>
> Has anyone else reported this or something similar?  Is anyone else
> working this problem?  Does anyone have a fix for the problem?
>
> Thanks,
> Bruce

Attachment: libpcap-prism.patch
Description:

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.