Sorry if any of this seems dumb, but I'm at a bit of a loss. I've used Wireshark in OSX for ages, and it's a dream; I fire it up, hit the checkboxes for "enable promiscuous mode" and "enable monitor mode," start sniffing, and see traffic for the whole network, as Wireshark puts the card into monitor mode. I can also use the Internet while that's happening. On this Kali live USB it's a whole different ballgame. I have to put the card into monitor mode myself, right? So I do that with airmon-ng and I get wlan0mon. At this point I can't use the Internet anymore, which is a bit of an inconvenience (is there a way to avoid this?) When I load up Wireshark at this point, I get an error message about running as a superuser: Lua: Error during loading: [string "/usr/share/wireshark/init.lua"]:44: dofile has been disabled due to running Wireshark as superuser. See https://wiki.wireshark.org/CaptureSetup/CapturePrivileges for help in running Wireshark as an unprivileged user. Would this be affecting my results? If I now select wlan0mon and start capturing, all I get are broadcasts from wi-fi routers within range. Perhaps interestingly, if I don't mess with airmon-ng at all, open Wireshark right when I boot, and capture with the dropdown box in Wireshark itself for promiscuous mode enabled (and leave monitor mode unselected; enabling it with that dropdown box causes an error), I do see traffic from another device on the wifi network, but it's always the Dropbox LAN Discovery Protocol. Any advice would be super appreciated! Thanks for your patience. asked 02 Jun '16, 13:02  frowning |
One Answer:
You've mentioned three issues which are actually independent. Starting from the last one, the Dropbox LAN discovery protocol uses a broadcast MAC address as destination, so you can see those packets even with both promiscuous and monitoring modes off, just like you would see any other traffic towards the broadcast MAC address. This kind of traffic is intended for everyone, you included. As for the Lua error, it is just Wireshark's counter-measure against the significant security risk coming from running Lua scripts while running as superuser, but it doesn't affect the way how capturing is done. In fact, Wireshark itself does not capture; it spawns another application called dumpcap, which is much simpler and thus less likely to contain security issues, and gets the captured frames from it. And dumpcap has to run with very high privileges to be able to capture on interfaces. As for how the monitoring mode works in Kali, I'd suppose the key here is the wireless driver and its capabilities which seem to be very different from those of the wireless driver of OS X. Promiscuous mode allows to deactivate the MAC address filter, so that the network card, wired or wireless, would not drop unicast frames with destination MAC address different from its own. But if such frames get filtered already earlier, based on other criteria, promiscuous mode won't help. Monitoring mode (now simplifying a lot) deactivates the SSID filter, i.e. it allows to capture wireless frames from other WLANs than the one to which your wireless card is currently associated, it deactivates the filter allowing to see only frames coming to your from the AP, so you can see also packets sent by other STAs to the AP and packets sent by the AP to other STAs, and it also changes the encapsulation of the captured frames, so that the WiFi - related information is available in the capture. It is a cool feature of the OS X wireless driver that it can use monitoring mode without switching off its own transmitter, I didn't know that (as I don't own a Mac). answered 02 Jun '16, 15:57  sindy showing 5 of 6 show 1 more comments |
Thanks for your thoughtful and informative answer.
Ha, so the transmitter being switched off is normal, then. I suppose I'm just spoiled by that nice Mac feature, then. I can live with that.
So if that's the case, is there a particular reason why the only traffic I would see in monitor mode is APs announcing themselves on the 802.11 protocol and no TCP, UDP, etc., or anything at all from other devices on my wifi network, as I do when I'm using it in OSX?
Probably because your hardware does not support it. Unfortunately, its a myth that 'monitor mode' automatically implies 'promiscuous mode'. The reality is that either due to bugs or design, not all wifi interfaces pass up all frames to the stack for capture. This has come up here before, you can search and see some of the other comments related to this.
I use a Mac, too, and that just works out of the box at least for a single channel. Now when I have to do multiple channels at the same time (i.e. when evaluating roaming performance) Linux is useful IF you have the right chipset and drivers. Check out the forum on http://www.aircrack-ng.org/ if you need some ideas on how you might get your hardware to work (new kernel, drivers with backports, whatever) or ideas on other adapters you could buy - many are inexpensive on Amazon.
There is a way to get your card to be usable as well when sniffing. Earlier versions of aircrack-ng had a different start up script that did what you want; that forum is full of complaints but I see why the developer made the change. I don't use his automated methods anymore anyway, as you can do it all by hand. What you want to do is add another interface through the iw command, like
(general) iw dev <devname> interface add <name> type <type>
(example) sudo iw phy phy0 interface add mon0 type monitor
This one would be in monitor mode and you could sniff with this one, but note it has to be on same channel as the main one (obviously - one radio). But I got tired of this - USB WiFi adapters that work are cheap enough (some in the $US10 range) so it's easier just to dedicate one for capture. Trick is finding the right chipset...
on top of what @Bob Jones wrote, there is also the encryption part of the puzzle. Unless the WLAN you sniff in is not encrypted, or unless you know the wireless passphrase and have met all pre-requisites necessary to allow Wireshark to decrypt the traffic, Wireshark cannot see whether the packet are TCP, UDP, or IP at all because the whole contents of the 802.11 frames including IP and higher protocol layers' headers is encrypted. So if you really can see only beacon frames and nothing else, the MAC filtering in the wireless driver is most likely the culprit; if you can see also wlan (802.11) frames of type "Data" and "QoS Data", encryption is most likely the reason why these are not displayed as TCP, UDP etc. which they actually are. But I am not sure how this would match the fact that you can see UDP and TCP in OS X mode. That would mean that either you don't use encryption in your WLAN, or that OS X decrypts the frames even in monitoring mode - but in that case, the monitoring would not be bit verbatim, so it would be useless for certain diagnostic tasks.
It didn't even occur to me that the same card would have different capabilities depending on the OS, so that's nice to know. Problematically, I don't think it's a hardware problem at this point, because I just plugged in and tried a USB wi-fi card that lots of people use for this very purpose (like @Bob Jones mentioned) and am still getting the same results.
I don't. It's literally just beacon signals (is this the right term?) from APs and nothing else. I have also tried this across a bunch of WLANs, encrypted and not, and ones that yeah, in OSX I didn't have to do anything to see the traffic on.
So I'm at a bit of a loss now. I'll keep plugging away and see if I get anywhere, though.
...and also because the on-board hardware works fine with OS X drivers as you wrote earlier. But @Bob Jones also wrote
(which is a more precise expression of the idea that different OSes give different results on the same hardware; actually, it is not enough to have the right OS, you must have the right driver for that OS. linux and even Windows can successfully monitor with some chipsets and drivers, but you have to be lucky. I am not, my Intel WLAN card with Intel drivers and npcap pretends that the monitoring works but the data cannot be decrypted).
However, what makes me really uncertain regarding what is actually going on at your end is that you say that with OS X you do not need to do anything to see data on encrypted WLANs. Can you try to capture, using OS X and the on-board WLAN card in monitoring mode, also some other device's communication (opening a web page from your mobile phone or other laptop associated to the same AP likey your Mac would do) and publish the resulting capture file (at Cloudshark or some plain file sharing service), login-free, and put a link to it here? I'd like to see what you really capture before taking any further assumptions.
As Sindy notes it's about the system - hardware, drivers, all of it.
This is complicated so takes some work to get going. I have a bag of USB wifi adapters to try in attempts to find stuff that works. And even then, it works on some systems and not others because of drivers. You still have not told us anything about what you are actually using. We know you can do this with a MAC, but nothing about the system that is having a problem. My Mac uses a broadcom chipset and is fine in Mac OS X. However, boot into Kali on the MAC and it's a mess - no support by default so I have to compile my own kernel module, and no proper monitor mode. And the kernel crashed when I turned the interface off...
What is the Linux system? Is it a PCI adapter or USB? What kernel? Is it up to date? What chipsets do you have - lspci or lsusb are useful commands. To get the kernel module in use try ethtool -i wlanx or whatever for your interfaces.