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

As we known, "wlan" is a display filter for wireless network, then I need a capture filter do the same thing, "wlan" just don't work with dumpcap. Any reply will be appreciated.

asked 24 Oct '13, 00:50

metamatrix's gravatar image

metamatrix
56161619
accept rate: 100%

edited 27 Oct '13, 19:08

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196

If you're capturing on a wireless network (and not getting pseudo-Ethernet frames), all frames would match "wlan", so filtering, while capturing on a wireless network, so that you only capture wireless network packets is pointless.

Are you trying to filter for particular types of 802.11 packets, or packets with particular RA, SA, DA, or TA addresses, or something such as that, so the display filter wouldn't be "wlan", it'd be "wlan.{something}"?

(24 Oct '13, 14:56) Guy Harris ♦♦

... and the capture filter would be wlan {something}. Refer to the pcap-filter man page for what {something} could be.

Edit: Hmm, but wlan alone should work as a capture filter. What's the output of dumpcap -v? Not sure when wlan was added; maybe your version of [Win|lib]pcap doesn't support it?

(24 Oct '13, 15:10) cmaynard ♦♦

Also, what's the output of dumpcap -i {interface} -L ... where {interface} is the name of the interface you're trying to capture on?

(24 Oct '13, 15:23) cmaynard ♦♦

wlan alone should work as a capture filter.

Nope. wlan is a "proto qualifier", so it can be used to qualify other qualifiers, such as wlan src host, but it can't be used by itself, just as, for example, ether can't. (You get "link layer applied in wrong context" as the error.)

I.e., there needs to be a "{something}" for wlan {something}.

(24 Oct '13, 16:40) Guy Harris ♦♦

Thanks for clarifying. The proto qualifier rules do seem a bit misleading to me though. I mean, the pcap-filter man page also lists ip, ip6, arp, rarp, decnet, tcp and udp as proto qualifiers, all of which you can use alone. To quote:

proto qualifiers restrict the match to a particular protocol. Possible protos are: ether, fddi, tr, wlan, ip, ip6, arp, rarp, decnet, tcp and udp.

Actually, further down the man page, it indicates that "tcp, udp, icmp [are] Abbreviations for: proto p where p is one of the above protocols". And in fact, you can use icmp alone as well, so perhaps it should also be listed with the other proto qualifiers? And you can also use icmp6 alone too, which isn't mentioned in either the proto qualifiers list or the proto p list.

Anyway, maybe you can understand my confusion when I saw wlan listed alongside the others, many of which can be used alone? Would it be worth clarifying the man page somehow?

(24 Oct '13, 19:34) cmaynard ♦♦

Thanks for all your replies.

1.I'm capturing wlan packets on an access controller, and I need all wlan packets, then what is the appropriate filter.

2.The dumpcap -v command shows as below. The filter "wlan addr2 0:2:3:4:5:6" works,but dumpcap show a rumtime error without any more error code or message.I've copied all the dll needed from the compile directory.

Dumpcap 1.10.3-dpi (SVN Rev Unknown from unknown)

Copyright 1998-2013 Gerald Combs [email protected] and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (32-bit) with GLib 2.34.1, with WinPcap (4_1_3), with libz 1.2.5, without POSIX capabilities, without libnl.

Running on 64-bit Windows 7 Service Pack 1, build 7601, without WinPcap. Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz, with 3772MB of physical memory.

(24 Oct '13, 20:48) metamatrix

the windows log of dumpcap error is: error app name: dumpcap.exe,ver: 1.10.3.0,timestamp: 0x525f5ef6 error module name: wpcap.dll,ver: 4.1.0.2980,timestamp: 0x51300419 exception code: 0x40000015 error offset: 0x00009fdc error process ID: 0x5918

(24 Oct '13, 23:08) metamatrix

The problem is that there are both proto qualifiers and protocol abbreviations, and some tokens, such as ip, ip6, tcp, and udp, serve both purposes, as they:

  1. correspond to protocols that have filterable items (protocols, ports) that multiple protocols understood by libpcap's filtering mechanism have, so they can be proto qualifiers (tcp port vs. udp port, ip address vs. ip6 address vs. ether address);
  2. correspond to protocols that have protocol types, so that they can be arguments to, for example, ip proto for tcp and udp or ether proto for ip or ip6.

icmp, however, is a protocol abbreviation (2 above), so you can use icmp alone as an abbreviation for ip proto icmp, but it's not a proto qualifier (i.e., not 1 above), as there's no icmp address or icmp port.

See Steve McCanne's Sharkfest 2011 presentation slides, starting with the "The Challenge" slide, for some discussion of the libpcap filter language.

Would it be worth clarifying the man page somehow?

Probably. File an issue at the libpcap issues list.

(25 Oct '13, 00:35) Guy Harris ♦♦

I'm capturing wlan packets on an access controller

...which means that "all wlan packets" means "all packets"...

and I need all wlan packets

...which means you want all packets...

then what is the appropriate filter

The appropriate filter is no filter, as you don't want to filter out any packets. (Filters exclude packets from the set of all packets; there are no filters that will give you more packets than using no filter at all.)

However:

Running on ... Windows ...

Unless you have an AirPcap device and are capturing with that, you will only be able to capture 802.11 data packets, and they will have fake Ethernet headers (so the filter wlan will match none of them), and you will only see packets going to and from your machine, not any other packets.

Furthermore:

... without WinPcap ...

it will not, in fact, be able to capture any packets, as WinPcap is the library that handles packet capture on Windows. (It's libpcap on UN*X; WinPcap is a port of libpcap to Windows, including a device driver needed to support packet capture.)

If dumpcap is crashing, it might be that it's not properly handling the lack of WinPcap. Unfortunately, Windows crash reports are extraordinarily useless for debugging these problems, as they give no stack trace information whatsoever.

I've copied all the dll needed from the compile directory.

That might not be sufficient.

(25 Oct '13, 00:49) Guy Harris ♦♦

In fact, I mirror the access controller's wire port(not wireless port) to my own machine's local link controller.So I can capture not only the wlan packets but also the packets on wire.Then I need a capture filter that only capture wlan packets.

(25 Oct '13, 02:02) metamatrix

Probably. File an issue at the libpcap issues list.

Filed as issue #326.

(25 Oct '13, 08:25) cmaynard ♦♦

A few more comments:

  • How are you able to capture any packets without WinPcap installed?
  • Have you tried capturing with the properly installed latest "off-the-shelf" version of dumpcap rather than your customized version to see if that resolves your run-time error?
  • If you somehow managed to capture packets, maybe you could post a small capture file to cloudshark or some other place of your choice so that it's easier to see what your packets look like and how best to differentiate, if possible, between the mirrored wired packets and the wireless packets of interest.
  • Maybe this is a dumb question, but why are you mirroring the wired packets so you can capture them ... but then trying to filter them out? Wouldn't it be easier to simply stop mirroring those other packets during the capture session of wlan traffic?
(25 Oct '13, 08:35) cmaynard ♦♦

In fact, I mirror the access controller's wire port(not wireless port) to my own machine's local link controller.So I can capture not only the wlan packets but also the packets on wire.

So, on the machine running Wireshark, which interfaces are you capturing on?

(25 Oct '13, 10:20) Guy Harris ♦♦

In fact, I mirror the access controller's wire port (not wireless port) to my own machine's local link controller.

O.K. then what you see is just the communication between the AP and the WLAN controller, which is most certainly TCP or UDP and encrypted! So, there is no filter at all you can apply to see wlan traffic, as those 'wlan frames' are forwarded to the controller via the encrypted 'tunnel' (like a VPN tunnel), from where it is forwarded to internal networks by the access controller (depends on the access controller configuration).

So, if you need the wireless frames, you can only capture directly via a wlan card (AirPcap on Windows or a supported card on Linux). If the traffic, that is transmitted via the AP, is sufficient you should be able to see that traffic on one of the ethernet ports of the access controller, as the frames need to be forwarded by the controller. In that case, just filter on the subnet that is assigned to the WLAN clients.

This all depends on your architecture, but in general that's the way it is done in a lot of companies.

Regards
Kurt

(25 Oct '13, 10:42) Kurt Knochner ♦

Sorry, when I use "add a comment", the page just says my post is spam, so I have to add an answer every time.

A few more comments:

How are you able to capture any packets without WinPcap installed?

I have a WinPcap dll in my system directory.

Have you tried capturing with the properly installed latest "off-the-shelf" version of dumpcap rather than your customized version to see if that resolves your run-time error?

I used 1.10.1 from official site, the same run-time error occured.

If you somehow managed to capture packets, maybe you could post a small capture file to cloudshark or some other place of your choice so that it's easier to see what your packets look like and how best to differentiate, if possible, between the mirrored wired packets and the wireless packets of interest. Maybe this is a dumb question, but why are you mirroring the wired packets so you can capture them ... but then trying to filter them out? Wouldn't it be easier to simply stop mirroring those other packets during the capture session of wlan traffic?

I need to find out wlan control and management messages such as associate/disassociate, authentication, and so on. http://www.cloudshark.org/captures/12defc616d65

(27 Oct '13, 18:24) metamatrix

Sorry, when I use "add a comment", the page just says my post is spam, so I have to add an answer every time.

  • So, on the machine running Wireshark, which interfaces are you capturing on? I captured on the "Local link" controller.

-O.K. then what you see is just the communication between the AP and the WLAN controller, which is most certainly TCP or UDP and encrypted! So, there is no filter at all you can apply to see wlan traffic, as those 'wlan frames' are forwarded to the controller via the encrypted 'tunnel' (like a VPN tunnel), from where it is forwarded to internal networks by the access controller (depends on the access controller configuration).

So, if you need the wireless frames, you can only capture directly via a wlan card (AirPcap on Windows or a supported card on Linux). If the traffic, that is transmitted via the AP, is sufficient you should be able to see that traffic on one of the ethernet ports of the access controller, as the frames need to be forwarded by the controller. In that case, just filter on the subnet that is assigned to the WLAN clients.

This all depends on your architecture, but in general that's the way it is done in a lot of companies.


My architecture is: the access controller's uplink and downlink are mirrored to my local PC's ethernet controller, and I want to get a capture filter just like the display filter "wlan".

Sample packets are at http://www.cloudshark.org/captures/12defc616d65 .

(27 Oct '13, 18:37) metamatrix
showing 5 of 16 show 11 more comments

http://www.cloudshark.org/captures/12defc616d65

OK, the 802.11 packets are encapsulated in LWAPP (RFC 5412) over UDP; Wireshark recognizes UDP traffic to or from ports 12222 and 12223 as LWAPP-over-UDP, so the capture filter you need in your particular situation is udp port 12222 or 12223.

permanent link

answered 27 Oct '13, 19:07

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

edited 27 Oct '13, 19:34

Thanks for the particular filter. An additional question is, if I want to select wlan control and management packets from all LWAPP packets(I don't need data packets), what's the particular filter?

(27 Oct '13, 23:48) metamatrix

if I want to select wlan control and management packets from all LWAPP packets(I don't need data packets), what's the particular filter?

please try this:

lwapp and (wlan.fc.type == 0 or wlan.fc.type == 1)

Regards
Kurt

permanent link

answered 28 Oct '13, 07:25

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 29 Oct '13, 05:04

Thanks for reply, but it's a display filter, and I need a capture filter.

(28 Oct '13, 20:38) metamatrix

This is the equivalent capture filter:

'udp port 12222 and udp[8]&4=0 and (udp[14]&12=0 or udp[14]&12=4)'

This will only work if the header lengths (IP and UDP) are constant. With UDP this will be the case. With IP things can change (and get tricky) if IP options are being used. However, according to your capture file, there are no IP options.

Regards
Kurt

(29 Oct '13, 04:58) Kurt Knochner ♦

Thank you, Kurt, it works :)

(30 Oct '13, 00:57) metamatrix

I know ;-))

(30 Oct '13, 05:55) Kurt Knochner ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×184
×76
×1

question asked: 24 Oct '13, 00:50

question was seen: 5,548 times

last updated: 30 Oct '13, 05:55

p​o​w​e​r​e​d by O​S​Q​A