tcpdump 3.9.5 ether host, ether src not working for wifi networks (DLT_PRISM_HEADER and DLT_IEEE802_11)

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

Hi,

I think I have found three problems with the code generated for wifi
networks for the expressions "ether host" or "ether src"  The first problem
is that the optimizer has removed some instructions that it should not.  The
second problem is if the optimizer is turned off the code generated is still
wrong.  The third problem is that the code could be better.  I could use
some help in confirming these are real problems and help in trying to find a
solution.  I have been digging into gencode.c, but the code is fairly
complex.  I think this problem is also in previous versions of libpcap.

Here is an example of the first problem:
[root@testorama tmp]# tcpdump -r test.dmp  -d  -s 0 "ether src
00:02:72:4e:b3:76"
reading from file test.dmp, link-type PRISM_HEADER (802.11 plus Prism
header)
(000) ldb      [144]
(001) jset     #0x4             jt 23   jf 2
(002) jset     #0x8             jt 7    jf 3
(003) ld       [156]
(004) jeq      #0x724eb376      jt 5    jf 7
(005) ldh      [154]
(006) jeq      #0x2             jt 22   jf 7
(007) jset     #0x8             jt 8    jf 23
(008) jset     #0x2             jt 9    jf 18
(009) jset     #0x1             jt 10   jf 14
(010) ld       [170]
(011) jeq      #0x724eb376      jt 12   jf 23
(012) ldh      [168]
(013) jeq      #0x2             jt 22   jf 23
(014) ld       [162]
(015) jeq      #0x724eb376      jt 16   jf 23
(016) ldh      [160]
(017) jeq      #0x2             jt 22   jf 23
(018) ld       [156]
(019) jeq      #0x724eb376      jt 20   jf 23
(020) ldh      [154]
(021) jeq      #0x2             jt 22   jf 23
(022) ret      #65535
(023) ret      #0

The optimizer has removed a ld instruction before instruction 7.  The result
of instruction 6 is that the accumulator has the half word from packet
offset 154.  The jf 7 takes it to instruction 7, but the comparison jset at
location 8 is against the value from packet offset 154.  Instruction 7
should really load the accumulator with a byte from packet offset 144 so
that it can determine if the packet is a data frame or not.

Here is an example of the second problem (same  expression without the
optimizer):
[root@testorama tmp]# tcpdump -r test.dmp  -d -O -s 0 "ether src
00:02:72:4e:b3:76"
reading from file test.dmp, link-type PRISM_HEADER (802.11 plus Prism
header)
(000) ldb      [144]
(001) jset     #0x4             jt 31   jf 2
(002) ldb      [144]
(003) jset     #0x8             jt 8    jf 4
(004) ld       [156]
(005) jeq      #0x724eb376      jt 6    jf 8
(006) ldh      [154]
(007) jeq      #0x2             jt 30   jf 8
(008) ldb      [145]
(009) jset     #0x8             jt 10   jf 31
(010) ldb      [145]
(011) jset     #0x2             jt 16   jf 12
(012) ld       [156]
(013) jeq      #0x724eb376      jt 14   jf 16
(014) ldh      [154]
(015) jeq      #0x2             jt 30   jf 16
(016) ldb      [145]
(017) jset     #0x2             jt 18   jf 31
(018) ldb      [145]
(019) jset     #0x1             jt 24   jf 20
(020) ld       [162]
(021) jeq      #0x724eb376      jt 22   jf 24
(022) ldh      [160]
(023) jeq      #0x2             jt 30   jf 24
(024) ldb      [145]
(025) jset     #0x1             jt 26   jf 31
(026) ld       [170]
(027) jeq      #0x724eb376      jt 28   jf 31
(028) ldh      [168]
(029) jeq      #0x2             jt 30   jf 31
(030) ret      #65535
(031) ret      #0

The instruction at location 8 is wrong.  It should be loading the byte from
packet offset 144 (and not 145) to determine if the frame is a data frame or
not.  I had a look at the function gen_wlanhostop() in gencode.c and it
looks like the gen_load_a() at line 2813 should be loading the byte from
packet offset 144.  I think there is a problem with the code at line 2813 as
I think it should read:
s = gen_load_a(OR_LINK, 0, BPF_B);

The third problem is that the code could be better.  The instruction at
between locations 4 and 7 inclusive are checking for a source address match
if it is a management frame.  The jf for the instruction at location 7 can
actually jump to location 31.  It has already determined the packet is a
management frame, so there is no point in continuing to check to see if the
frame is a data frame (instructions from location 8 on).

Are these real problems or am I mistaken?

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