Bug 207435 - TCPDUMP 3.9.4 generates the wrong BPF for DLT_PRISM_HEADER
TCPDUMP 3.9.4 generates the wrong BPF for DLT_PRISM_HEADER
Product: Fedora
Classification: Fedora
Component: tcpdump (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Miroslav Lichvar
Depends On:
  Show dependency treegraph
Reported: 2006-09-20 23:05 EDT by Bruce Keats
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-14 04:14:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bruce Keats 2006-09-20 23:05:42 EDT
Description of problem:
This is an except from the email discussion of the problem on the TCPDUMP 
workers mailing list.  The upshot is that the problem should be fixed in the 
next verion of tcpdump (TCPDUMP 3.9.5) which is available.

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".

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.tcpdump -i athm0 -s0 -d ip

Actual Results:
tcpdump: WARNING: athm0: no IPv4 address assigned 
(000) ldh      [318]
(001) jeq      #0x800           jt 2    jf 3
(002) ret      #65535
(003) ret      #0

Expected Results:
(000) ldh      [174]
(001) jeq      #0x800           jt 2    jf 3
(002) ret      #65535
(003) ret      #0

Additional info:
athm0 happens to be point to a card that supports DLT_PRISM_HEADER.

The web site above is a pointer to the discussion on the tcpdump workers 
mailing list.  Look for the topic: TCPDUMP 3.9.4 under Fedora Core 5 seems to 
generate the wrong BPF for DLT_PRISM_HEADER.

Since the BPF is wrong, do data makes it past the filter, so no data is 
captured.  I assume this is what is meant by severity.

I have also raised a bug report against FC6test3 (206686)
Comment 1 Miroslav Lichvar 2006-11-08 11:40:21 EST
tcpdump-3.9.4-3.fc5 is built with the patch, should be in updates-testing soon.
Can you check it out?

Note You need to log in before you can comment on or make changes to this bug.