This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Capture Filter for EAPOL packets does not show anything

0

I am trying to capture only the EAPOL packets from my WLAN. I have read on the CaptureFilters wiki page that this should work with:

ether proto 0x888e

But when i put that into wireshark it does not capture anything.

So i played with the display filters, i think the equivalet there is:

eth.type == 0x888e

which also shows nothing on a data set that definitely contains EAPOL packets. Instead i could just set:

eapol

as the display filter and it works perfectly, the right packets show up.

Is it possible to set that somehow as capture filter? Bug in Wireshark or wrong filter?

asked 03 Jan '16, 13:59

Jake's gravatar image

Jake
6●1●1●3
accept rate: 0%

edited 03 Jan '16, 14:02

Do the packets you're capturing display in Wireshark/TShark with Ethernet headers or 802.11 headers? If they show 802.11 headers (from what is probably a monitor mode capture), eth.type won't be a valid field - you'll need to use llc.type, as Bob Jones indicated.

If you use a display filter of eapol:

  • if the packets have an Ethernet header, what value do the EAPOL packets have in the Ethernet type field?
  • if the packets have an LLC and SNAP header, what are the OUI and PID values in the SNAP header for the EAPOL packets?
(03 Jan '16, 15:22) Guy Harris ♦♦

Yes, it is a wpa handshake with 802.11 headers from my card in monitor mode.

(03 Jan '16, 16:43) Jake

OK, so what are the OUI and PID values in the SNAP header for the EAPOL packets?

(03 Jan '16, 16:49) Guy Harris ♦♦

I am not sure what OUI/PID are, so here is the whole LLC header:

Logical-Link Control
    DSAP: SNAP (0xaa)
        1010 101. = SAP: SNAP
        .... ...0 = IG Bit: Individual
    SSAP: SNAP (0xaa)
        1010 101. = SAP: SNAP
        .... ...0 = CR Bit: Command
    Control field: U, func=UI (0x03)
        000. 00.. = Command: Unnumbered Information (0x00)
        .... ..11 = Frame type: Unnumbered frame (0x03)
    Organization Code: Encapsulated Ethernet (0x000000)
    Type: 802.1X Authentication (0x888e)
(04 Jan '16, 01:23) Jake

If you select the Type: 802.1X Authentication (0x888e) item in the packet details pane, then, in the hex/ASCII dump pane, does it show data in the "Frame" tab or the "Decrypted WEP data"/"Decrypted CCIP data"/"Decrypted TKMP data" tab of that pane?

(04 Jan '16, 02:22) Guy Harris ♦♦

What tabs? I see only these 2 bytes highlighted in the hex pane after selecting that.

(04 Jan '16, 03:23) Jake

The hex pane doesn't have two named tabs?

(04 Jan '16, 12:02) Guy Harris ♦♦

No. I dont have added any WPA decryption keys to the config so far, thats probably the reason.

Have you read the comments under Bob Jones Answer? An idea why is that?

(05 Jan '16, 05:39) Jake

So the frame you're showing hasn't been decrypted? And you're capturing in monitor mode? But when you capture with ether photo 0x888e, packets like that one aren't captured?

(05 Jan '16, 12:06) Guy Harris ♦♦

Yes, yes and yes. (*proto not photo)

(05 Jan '16, 12:25) Jake

(*proto not photo)

(Damn you autocorrect!)

So, in the capture options dialog, is there a "Compile BPFs" or "Compile selected BPFs" button? If so, what gets shown if, before starting a capture with the filter ether proto 0x888e, you push that button? It should pop up a window with text; what's the text?

(05 Jan '16, 12:46) Guy Harris ♦♦

(Why won't OSQA allow a comment to begin with fixed-width text?)

(000) ldb      [3]
(001) lsh      #8
(002) tax      
(003) ldb      [2]
(004) or       x
(005) st       M[0]
(006) tax      
(007) txa      
(008) add      #24
(009) st       M[1]
(010) ldb      [x + 0]
(011) jset     #0x8             jt 12   jf 28
(012) jset     #0x4             jt 28   jf 13
(013) jset     #0x80            jt 14   jf 17
(014) ld       M[1]
(015) add      #2
(016) st       M[1]
(017) ld       [4]
(018) jset     #0x2000000       jt 19   jf 28
(019) jset     #0x1000000       jt 20   jf 22
(020) ldb      [16]
(021) jset     #0x20            jt 24   jf 28
(022) ldb      [8]
(023) jset     #0x20            jt 24   jf 28
(024) ld       M[1]
(025) add      #3
(026) and      #0xfffffffc
(027) st       M[1]
(028) ldx      M[0]
(029) ldb      [x + 0]
(030) jset     #0x4             jt 38   jf 31
(031) ldx      M[0]
(032) ldb      [x + 0]
(033) jset     #0x8             jt 34   jf 38
(034) ldx      M[1]
(035) ldh      [x + 6]
(036) jeq      #0x888e          jt 37   jf 38
(037) ret      #262144
(038) ret      #0

(Why does it always change the layout after posting?)

(05 Jan '16, 13:04) Jake

(Why does it always change the layout after posting?)

Because it assumes most of what you're typing is free-form text, which it wraps. If you want fixed-formatted text, you either need to put it in backquotes or begin each line with 4 spaces. (And you can't begin a comment with a 4-space indent, which is why I added the parenthesized note to your comment.)

(05 Jan '16, 13:37) Guy Harris ♦♦
showing 5 of 13 show 8 more comments

One Answer:

0

I use ether proto 0x888e as a capture filter in Windump or tcpdump, such as:

C:\traces>windump -i 1 -s 1600 -w EAPOL -W 200 -C 200 ether proto 0x888e

but it's really only good for the 4-way WPA handshake. Group rekeys are encrypted, so tougher to get. Share your trace and we can have a look. Exactly where do you put this filter when configuring?

eth.type == 0x888e

If it is a trace with 802.11 headers, this will likely not work. Try:

llc.type == 0x888e

Without capture filter: alt text

With Capture filter in place: alt text

answered 03 Jan '16, 15:10

Bob%20Jones's gravatar image

Bob Jones
1.0k●2●5●15
accept rate: 21%

edited 04 Jan '16, 05:13

I put that into the display filter field (in the Wireshark gui), but eth.type was just a guess, i understand now that this is a other header and it works fine with llc.type. My question ist still how to set that as capture filter?

(03 Jan '16, 16:45) Jake

I just did a test on Windows with Wireshark - with a capture filter of

ether proto 0x888e

At the same time, I ran another Wireshark process but this time with no capture filter, with only a display filter of eapol and confirm both show the same exact packets. Note that the open capture had 40K+ total packets, displaying only 15, while the capture filter Wireshark only captured and display 15. If I can get a screenshot posted, I will do so.

This is on a Windows7 system with AirPcapNx.

(04 Jan '16, 05:07) Bob Jones

Thanks for your effort! But i did the same test, my capture options are exactly the same as on the screenshoot and i get nothing. I tried some of the other capture filter presets and they all worked, even "ether proto" with other numbers (for example 0x0800 - IPv4). So is it a bug?

Wireshark 2.0.0 (from the offical repo) on Manjaro Linux.

(04 Jan '16, 08:11) Jake

Tested on Kali2 w/ Wireshark 1.12.6 (whatever is in the repository) and it works as expected, just like my Windows screenshots. Maybe you found something with Wireshark2/Linux?

(04 Jan '16, 08:57) Bob Jones

Okay, so i tested it with Kali 2 and got nothing again...

Then i found out that the wlan adapter has something to do with it: All the tests were on my Intel 3160, if i use a USB TL-WN722N instead i get at least some packets, but only 1-2 from a 4 way handshake (totally random which one), while the 2.Wireshark without filter captures all.

(04 Jan '16, 10:37) Jake