What is the correct BPF filter for only recieving packets where the source MAC address is equal to the transmission MAC address?
Looking at the documentation, it seems like the fields should be available through either wlan[21:12] or wlan.addr2 but I'm unable to get those to work.
According to the pcap-filter manpage, capture filters for tshark or Wireshark don't support comparing packet fields against each other.
You can, however, do that with the display filter (top bar in Wireshark, once capture started):
wlan.sa == wlan.ta
To check whether the DS flag is equal to 0x1 using a capture filter, you can do the following:
wlan[1] & 3 = 1
It retrieves the second byte of the wlan header (wlan[1]), masks the 2 lower bits (& 3), and compares the result to 1.
Related
I've set Wireshark's capture filter set to capture only packets from the MAC address of interest, but the result is dominated by zillions of packets whose Protocol is "802.11". I want to view all of the packets that are NOT 802.11, e.g. ARP, DCHP, DNS, TCP, etc.
For example, in the following, I'd like to hide all of the 802.11 packets and show the DHCP packets (and any others that are NOT 802.11):
I tried "wlan.fc.type != 0", but clearly that's not correct. What's the magic keyword for such a filter?
update
#ChristopherMaynard's comment is close, and I now understand that a simple filter of:
ip
is almost what I want, but it fails to display packets of type ARP, EAPOL, LLC, MDP and perhaps others.
[Converted comment to answer and added an alternate solution while I'm at it.]
If you just want data frames but those without un-dissected data (which would still show 802.11 in the Protocol column), then you could try wlan.fc.type == 2 and !data. Or you could try !(frame.protocols == "radiotap:wlan_radio:wlan:data" or frame.protocols == "radiotap:wlan_radio:wlan").
Another alternative is to download the filtcols.lua script written by Chuck Craft, save it to your plugins directory (Wireshark: Help -> About Wireshark -> Folders -> Personal Lua Plugins), the [re]start Wireshark. Now you can apply a display filter such as wlan and !(filtcols.protocol == "802.11").
I want to know if my Wi-Fi card supports MIMO (Multiple Input Multiple Output), and specifically how to find the number of antennas.
Is there a command I can run to find out?
If you're using windows type in command line: netsh wlan show all | find /I “MIMO”.
If you see MU-MIMO : Supported then it means yes.
I'm not sure how to do this in Linux aside from checking network card model and looking at technical specification. That will give you 100% correct answer.
But You can try though this: iw phy | grep index; you will see something like this:
HT TX/RX MCS rate indexes supported: 0-15
If you see the index above 7 that means your card supports MIMO. Why is that ?
MIMO requires at least two antennas to work (means two spatial streams of data) and this table explains index / streams relation.
Is it possible to re-do numbering in Wireshark. For example i have filtered packets to one side:
So the numbers are (they are not in order because of filtering):
416,419,420,423,424,426,427.
But i would like to number them like this, line by line:
1,2,3,4,5,6,7
The reason is that it would be easier to count all the packets. I know tshark has statistical operation COUNT, but for quick counting this would be a lot better.
You can export the displayed packets into a new file via File -> Export Specified Packets... -> All packets: Displayed. The new capture file will contain sequentially numbered packets starting from 1.
But if you just want to know how many displayed packets there are, you could just look at the Wireshark status line where it will indicate the number of displayed packets.
Statistics -> Capture File Properties will also tell you the number of displayed packets.
I was watching several wifi captures in wireshark and I bumped into two specimens I had never seen before. First of all, I thought that a IEEE 802.11 data frame would always be followed by a LLC header (802.2), provided that the frame actually contained data. Now I have a two wireshark captures showing otherwise !
First one, we can see an Ethernet II header following the wifi header :
Now that's the first thing I don't understand. How is an interface supposed to know, when reading the 802.11 Data header, that it is going to be an Ethernet II following ? There is no field in the 802.11 header specifying what's coming next.
Second is "raw data" directly following the wifi header.
Same question as before, how are we supposed to know that Data was following, and not LLC ?
First question:
To quote a comment in the Wireshark 802.11 dissector:
/* I guess some bridges take Netware Ethernet_802_3 frames,
which are 802.3 frames (with a length field rather than
a type field, but with no 802.2 header in the payload),
and just stick the payload into an 802.11 frame. I've seen
captures that show frames of that sort.
There is no field in the header that says "this is a bridged Netware Ethernet_802_3 frame", so Wireshark has to use a heuristic. The heuristic is "if the first two bytes of the payload are not both 0xAA, the first 6 bytes of the payload equal the destination MAC address, and the next 6 bytes of the payload equal the source MAC address, then this is a bridged Netware Ethernet_802_3 frame", in which case it calls the Ethernet dissector. Because this is a heuristic, it is, of course, not guaranteed to get the correct answer all the time.
IEEE Std 802.11-2012 says, in section 5.1.4 "MSDU format":
This standard is part of the IEEE 802 family of LAN standards, and as such all MSDUs are LLC PDUs as defined in ISO/IEC 8802-2: 1998. In order to achieve interoperability, implementers are recommended to apply the procedures described in ISO/IEC Technical Report 11802-5:1997(E) (previously known as IEEE Std 802.1H-1997 [B21]), along with a selective translation table (STT) that handles a few specific network protocols, with specific attention to the operations required when passing MSDUs to or from LANs or operating system components that use the Ethernet frame format. Note that such translations may be required in a STA.
"ISO/IEC 8802-2: 1998" is also ANSI/IEEE Std 802.2, 1998 Edition, so that says that the payload should begin with an 802.2 header. At least as I read IEEE Std 802.1H-1997, Ethernet frames without an 802.2 header should be translated to SNAP frames, using their Ethernet type value, when bridged to a LAN using 802.2, such as an 802.11 LAN. I guess, since Netware Ethernet_802_3 frames don't have a valid 802.2 LLC header and don't have a type field (they have a length field; I think that, as they don't have an 802.2 header following the Ethernet header, this means that they technically aren't valid Ethernet frames), they aren't covered by the specifications in question, so it's not technically a protocol error to just put the Ethernet packet, starting with the Ethernet header, into the data field. Presumably those packets are sent only to bridges, under the assumption that the bridge knows how to Do The Right Thing.
Second question:
The most common reason to see "Data" after an 802.11 header is that the packet in question is encrypted (WEP or WPA/WPA2) and Wireshark doesn't have the password for the network (and, for WPA/WPA2 Personal/Pre-shared key mode, doesn't have the initial EAPOL handshake in the capture; decrypting in Enterprise/802.1X mode is not supported).
Are you capturing on a "protected" (WEP or WPA/WPA2) network?
I'm trying to parse 802.11 frames myself and I've encountered two problems that I can't solve.
First of all, when does an LLC (Logical Link Control) header follow a IEEE 802.11 data frame ? I thought when there is data in a frame, there would always be an llc overhead preceding the data, but I have a wireshark with Ethernet II instead of LLC. But I have no idea how to actually know if it's gonna be an LLC or a Ethernet II header following my 802.11 data header. There's no field in the 802.11 header specifyin what's following.
Secondly, I have noticed something in wireshark when I open a capture file containing 802.11 QoS data frames. At the end of the header there's the QoS control field, which is normal, it's specified in the IEEE 802.11 documentation (i've read it over and over again to try to find an answer to my question) But then, there's 2 bytes that wireshark considers part of the 802.11 header (when you click on the raw bytes, wireshark points to the 802.11 header, but the signification of the bytes is not displayed in the fields of the header ! Does my question make any sense ?
Here are images to explain what I'm not understanding. On the first screen shot below, you see the 802.11 header selected and you see below the concerned bytes in hexadecimal.
Pay attention to the last bytes of this packet:00 00 10 aa
Now I expand the 802.11 header and click on the very last field of it (QoS control, as specified in the RFC). You can see that the corresponding bytes are 00 00. But those bytes are not the last bytes of the packet ! There still is 10 aa that's part of the wifi packet but I have no idea what those bytes represent !
Any one has an idea ?
First of all, when does an LLC (Logical Link Control) header follow a IEEE 802.11 data frame ?
There should always be one, although things might be odd for aggregate packets. If you capture on an 802.11 interface and you're not capturing in monitor mode, you might see the packet begin with an Ethernet header, but that's different - that's the adapter and/or the driver translating the 802.11 header + LLC header into an Ethernet header.
But then, there's 2 bytes that wireshark considers part of the 802.11 header
That might actually be the "Atheros padding", "helpfully" inserted, in monitor mode, between the 802.11 header and the frame body by some Atheros network adapters. Open up the Radiotap header and see if the "Data Pad" flag is set in the Flags field; if so, the packet has "Atheros padding".