Capture filter on wireless OUI

Question

I am using Wireshark 1.12.4 on Fedora. I am trying to use a capture filter to lessen the quantity of data I am storing to disk at a customer's site where I am logging traffic to trace an issue. They have 10 radios and I would like to capture all traffic to/from the radios and ignore everything else. This is rather trivial in the display filter as I can use

wlan.addr contains aa:bb:cc

with the OUI of the device since they are all the same vendor.

However, I'm not having luck with doing the same with a capture filter. The closest I have come is (wlan[0:4] & 0xFFFFFF00) == 0xAABBCC00 as the capture filter at least turned green on input. However, when I tried this, I did not get any packets captured.

Thanks!

Answer 1

0

Let's look at the BPF code of the following filter:

wlan host aa:bb:cc:dd:ee:ff

Run the following command to dump the BPF code

dumpcap -d -f "wlan host aa:bb:cc:dd:ee:ff"

Output:

(000) ld       [8]
(001) jeq      #0xccddeeff      jt 2    jf 4
(002) ldh      [6]
(003) jeq      #0xaabb          jt 8    jf 4
(004) ld       [2]
(005) jeq      #0xccddeeff      jt 6    jf 9
(006) ldh      [0]
(007) jeq      #0xaabb          jt 8    jf 9
(008) ret      #262144
(009) ret      #0

As you can see, this working wlan filter reads 4 or 2 bytes (ld, ldh) at different positions [8,6,2,0], which is equal 6 bytes for dst addr (starting at [0]) and 6 bytes for src addr (starting at [6]).

Now let's check your filter:

dumpcap -d -f "(wlan[0:4] & 0xFFFFFF00) == 0xAABBCC00"

Output:

(000) ld       [0]
(001) and      #0xffffff00
(002) jeq      #0xaabbcc00      jt 3    jf 4
(003) ret      #262144
(004) ret      #0

Your filter reads 4 bytes (ld) at position [0], so it should at least capture frames with dst addr of aa:bb:cc:*

I guess you would need the frames with src addr aa:bb:cc:* as well, so what you need is a combination of both.

Solution:

dumpcap -d -f "(wlan[0:4] & 0xFFFFFF00) == 0xAABBCC00 or (wlan[6:4] & 0xFFFFFF00) == 0xAABBCC00"

Output:

(000) ld       [0]
(001) and      #0xffffff00
(002) jeq      #0xaabbcc00      jt 6    jf 3
(003) ld       [6]
(004) and      #0xffffff00
(005) jeq      #0xaabbcc00      jt 6    jf 7
(006) ret      #262144
(007) ret      #0

I did not test that filter, but the BPF code looks O.K., so it should work.

Regards
Kurt

answered 25 Mar '15, 17:38

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

Well, it does appear to be a valid filter but when I apply it, I don't capture any packets.

I looked at the output of the generated code and see that it is different for the wireless interface vs the default. Not sure if that explains it. Here it is for both (OUI is 00:aa:bb)

  $ dumpcap -i wlan4 -d -f "(wlan[0:4] & 0xFFFFFF00) == 0x00aabb00 or (wlan[6:4] & 0xFFFFFF00) == 0x00aabb00"
  Capturing on 'wlan4'
  (000) ldb      [3]
  (001) lsh      #8
  (002) tax      
  (003) ldb      [2]
  (004) or       x
  (005) tax      
  (006) ld       [x + 0]
  (007) and      #0xffffff00
  (008) jeq      #0xaabb00        jt 12   jf 9
  (009) ld       [x + 6]
  (010) and      #0xffffff00
  (011) jeq      #0xaabb00        jt 12   jf 13
  (012) ret      #65535
  (013) ret      #0
$ dumpcap  -d -f "(wlan[0:4] & 0xFFFFFF00) == 0x00aabb00 or (wlan[6:4] & 0xFFFFFF00) == 0x00aabb00"
Capturing on 'eth0'
(000) ld       [0]
(001) and      #0xffffff00
(002) jeq      #0xaabb00        jt 6    jf 3
(003) ld       [6]
(004) and      #0xffffff00
(005) jeq      #0xaabb00        jt 6    jf 7
(006) ret      #65535
(007) ret      #0

(26 Mar ‘15, 06:00) shadowrider

Its also interesting that the code for the simple filter is quite different for the wireless interface vs the default:

$ dumpcap  -i wlan4 -d -f "wlan host aa:bb:cc:dd:ee:ff"
Capturing on 'wlan4'
(000) ldb      [3]
(001) lsh      #8
(002) tax   

(003) ldb      [2]
(004) or       x
(005) st       M[0]
(006) tax   

(007) ldb      [x + 0]
(008) jset     #0x4             jt 40   jf 9
(009) jset     #0x8             jt 10   jf 31
(010) ldb      [x + 1]
(011) jset     #0x2             jt 12   jf 21
(012) jset     #0x1             jt 13   jf 17
(013) ld       [x + 26]
(014) jeq      #0xccddeeff      jt 15   jf 27
(015) ldh      [x + 24]
(016) jeq      #0xaabb          jt 39   jf 27
(017) ld       [x + 18]
(018) jeq      #0xccddeeff      jt 19   jf 35
(019) ldh      [x + 16]
(020) jeq      #0xaabb          jt 39   jf 35
(021) ld       [x + 12]
(022) jeq      #0xccddeeff      jt 23   jf 25
(023) ldh      [x + 10]
(024) jeq      #0xaabb          jt 39   jf 25
(025) ldb      [x + 1]
(026) jset     #0x1             jt 27   jf 35
(027) ld       [x + 18]
(028) jeq      #0xccddeeff      jt 29   jf 40
(029) ldh      [x + 16]
(030) jeq      #0xaabb          jt 39   jf 40
(031) ld       [x + 12]
(032) jeq      #0xccddeeff      jt 33   jf 35
(033) ldh      [x + 10]
(034) jeq      #0xaabb          jt 39   jf 35
(035) ld       [x + 6]
(036) jeq      #0xccddeeff      jt 37   jf 40
(037) ldh      [x + 4]
(038) jeq      #0xaabb          jt 39   jf 40
(039) ret      #65535
(040) ret      #0
$ dumpcap  -d -f "wlan host aa:bb:cc:dd:ee:ff"
Capturing on 'eth0'
(000) ld       [8]
(001) jeq      #0xccddeeff      jt 2    jf 4
(002) ldh      [6]
(003) jeq      #0xaabb          jt 8    jf 4
(004) ld       [2]
(005) jeq      #0xccddeeff      jt 6    jf 9
(006) ldh      [0]
(007) jeq      #0xaabb          jt 8    jf 9
(008) ret      #65535
(009) ret      #0

(26 Mar ‘15, 06:53) shadowrider

Packets from “eth0” have Ethernet headers, which have a fixed length and format and have only two MAC addresses to test. Packets from “wlan4” have 802.11 headers, which have a variable length and format and have somewhere between two and four MAC addresses to test; that causes the code to be more complicated and, due to limitations in the BPF compiler’s optimizer, require that the optimizer be disabled, so that the optimizer can’t do any simplifications of the code.

(26 Mar ‘15, 14:31) Guy Harris ♦♦

And the variable-length-and-format headers also mean that you have to know whether the packet has 2, 3, or 4 MAC addresses in order to know at what offsets the MAC addresses are.

(26 Mar ‘15, 14:32) Guy Harris ♦♦