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

Cannot Capture Frames Other Than Broadcast or Multicast over WLAN

0

I have searched almost every forum on this topic but couldn't find a correct answer so I hope you can help.

My problem is I cannot capture any frames other than broadcast or multicast over wireshark on my WLAN interface (eg. no ICMP packets, no HTTP packets, etc.)

Please follow details below:

  • OS: Linux KALI 2016.1 Rolling Release 64bit (u#1 SMP Debian 4.3.3-5kali4)
  • NIC: Linksys WUSB600Nv2 Dual-Band (RaLink RT3572 - Driver: rt2800usb - mac80211: capable - Assigned as WLAN0)
  • WLAN0 put to monitor mode (using airmon-ng start wlan0) therefore listening on wlan0mon Channel 01 on Wireshark
  • Test AP: Linksys E3000 on Channel 01 - Open security no encryption
  • Second Client: Win7 Laptop pinging the AP (ICMPv4) & Surfing web
  • Wireshark version 2.0.3

However cannot capture any UNICAST frames, please tell me what I am missing, Thanks

asked 06 Jun '16, 23:18

bahmanthegreat's gravatar image

bahmanthegreat
10114
accept rate: 0%

Not an authoritative answer - you may be missing a proper driver which would let through all frames captured in monitoring mode, regardless their destination MAC address. This seems obvious but some drivers' authors think otherwise so monitoring mode doesn't automatically mean promiscuous mode, and there is currently no chance to ask the driver for both simultaneously.

Alternatively, the driver may be OK but you forgot about WPA security - Wireshark cannot recognize any packets as ICMP, HTTP etc. without decrypting them first.

So to choose the right possibility: can you see any other destination MAC addresses than broadcast and multicast (and your own one) in the captured frames?

(07 Jun '16, 00:56) sindy

Thanks for the quick reply Sindy,

To clarify: 1. No encryption is applied to the SSID, it's open. 2. I do not receive any frames for destinations other than Broadcast/Multicast. 3. I do not receive frames destined to my own station unless I am connected to the AP (which beats the purpose if I do because I have to change out of monitor mode) 4. I have tried filtering out the broadcast/multicast frames from the capture and the output showed no frames at all. 5. No firewall is running, no antiviruses. 6. I can see ARP requests, SSDP, NBNS, IGMP, etc. but no unicast traffic.

How can I make sure I have the correct driver?

(07 Jun '16, 01:29) bahmanthegreat

I'm afraid that only by reading the driver's code, and patching it if necessary.

(07 Jun '16, 02:36) sindy

One Answer:

1

That Kernel, if I recall, has a regression for monitor mode with RT chipsets:

http://marc.info/?l=linux-wireless&m=145311668331789&w=2

On Kali Rolling, try to get to this kernel or later:

4.4.0-kali1-amd64 #1 SMP Debian 4.4.6-1kali1 (2016-03-18) x86_64 GNU/Linux

I capture regularly with RT chipsets but had to work around that driver issue by upgrading kernels.

To upgrade the kernel, try

apt-get upgrade linux-image

You can see what kernels are available with:

/home/admin/horst-git# apt-cache search linux-image
linux-headers-4.4.0-kali1-amd64 - Header files for Linux 4.4.0-kali1-amd64
linux-image-4.4.0-kali1-amd64 - Linux 4.4 for 64-bit PCs
linux-image-4.4.0-kali1-amd64-dbg - Debugging symbols for Linux 4.4.0-kali1-amd64
linux-image-amd64 - Linux for 64-bit PCs (meta-package)
linux-image-amd64-dbg - Debugging symbols for Linux amd64 configuration (meta-package)
nvidia-kernel-4.4.0-kali1-amd64 - NVIDIA binary kernel module for Linux 4.4.0-kali1-amd64
linux-image-4.3.0-kali1-amd64 - Linux 4.3 for 64-bit PCs

answered 07 Jun '16, 02:56

Bob%20Jones's gravatar image

Bob Jones
1.0k2515
accept rate: 21%

Bob you are a genius! Upgrading the kernel solved the problem.

Many thanks.

(07 Jun '16, 04:47) bahmanthegreat
1

I note your very detailed question. Most just put 'It doesn't work' and rarely provide a capture file. With the detail you provided it was possible to go right to work and figure out what is wrong. Technically, this isn't a Wireshark issue but rather a hardware/driver problem.

OK, I get why people won't put kernel versions and such, even though it can be important, but this is a Wireshark site, and some of the other people here really know what they are doing. So why people won't put up a capture file for those experts to look at until it is practically ripped out of them is beyond me...

(07 Jun '16, 06:02) Bob Jones