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 edited 27 Oct '13, 19:08  Guy Harris ♦♦ showing 5 of 16 show 11 more comments |
2 Answers:
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 answered 27 Oct '13, 19:07 Guy Harris ♦♦ 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 |
please try this:
Regards answered 28 Oct '13, 07:25  Kurt Knochner ♦ 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:
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 (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 ♦ |
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}"?
... and the capture filter would be
wlan {something}. Refer to the pcap-filter man page for what{something}could be.Edit: Hmm, but
wlanalone should work as a capture filter. What's the output ofdumpcap -v? Not sure whenwlanwas added; maybe your version of [Win|lib]pcap doesn't support it?Also, what's the output of
dumpcap -i {interface} -L... where {interface} is the name of the interface you're trying to capture on?Nope.
wlanis a "proto qualifier", so it can be used to qualify other qualifiers, such aswlan src host, but it can't be used by itself, just as, for example,ethercan't. (You get "link layer applied in wrong context" as the error.)I.e., there needs to be a "{something}" for
wlan {something}.Thanks for clarifying. The proto qualifier rules do seem a bit misleading to me though. I mean, the
pcap-filterman 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?
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.
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
The problem is that there are both proto qualifiers and protocol abbreviations, and some tokens, such as
ip,ip6,tcp, andudp, serve both purposes, as they:tcp portvs.udp port,ip addressvs.ip6 addressvs.ether address);ip protofortcpandudporether protoforiporip6.icmp, however, is a protocol abbreviation (2 above), so you can useicmpalone as an abbreviation forip proto icmp, but it's not a proto qualifier (i.e., not 1 above), as there's noicmp addressoricmp port.See Steve McCanne's Sharkfest 2011 presentation slides, starting with the "The Challenge" slide, for some discussion of the libpcap filter language.
Probably. File an issue at the libpcap issues list.
...which means that "all wlan packets" means "all packets"...
...which means you want all packets...
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:
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
wlanwill match none of them), and you will only see packets going to and from your machine, not any other packets.Furthermore:
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.
That might not be sufficient.
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.
Filed as issue #326.
A few more comments:
So, on the machine running Wireshark, which interfaces are you capturing on?
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
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:
I have a WinPcap dll in my system directory.
I used 1.10.1 from official site, the same run-time error occured.
I need to find out wlan control and management messages such as associate/disassociate, authentication, and so on. http://www.cloudshark.org/captures/12defc616d65
Sorry, when I use "add a comment", the page just says my post is spam, so I have to add an answer every time.
-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 .