Cannot disable promiscuous mode
-
Are you certain promisc is causing you a problem? Why do you want to disable it?
I believe that's just how it's supposed to operate in that mode.
-
Are you certain promisc is causing you a problem? Why do you want to disable it?
I believe that's just how it's supposed to operate in that mode.
I want to put the interface in monitor mode to capture WiFi frames. Supposedly it is promiscuous mode that causes tcpdump to capture network packets instead of data-link frames. (I know, it is an odd purpose for pfSense..)
-
By default tcpdump puts an interface into promiscuous mode to capture all datalink frames arriving at the interface. (In non-promiscuous mode the NIC accepts only frames addressed to its MAC address, the broadcast address and certain enabled multicast addresses.)
So why do you want to disable promiscuous mode? (I suspect you don't correctly understand promiscuous mode. See description of promiscuous mode in the description of the addm parameter in the ifconfig man page at http://www.freebsd.org/cgi/man.cgi?query=ifconfig&apropos=0&sektion=0&manpath=FreeBSD+9.1-RELEASE&arch=default&format=html )
-
It's been a while since I played around with wifi at the base level but I seem to recall that the hardware cannot be in both hostap mode and monitor mode (or any other mode). Since pfSense does not allow you to select anything but hostap, infrastructure and ad-hoc you may not be able to this, at least not easily.
If you are using virtual APs the interface will need to be in promiscuous mode since each AP has its own MAC. The card must respond to packets addressed to the virtual MAC.Steve
Edit: typo
-
It looks like you're bridging, which requires promiscuous mode to function.
-
By default tcpdump puts an interface into promiscuous mode to capture all datalink frames arriving at the interface. (In non-promiscuous mode the NIC accepts only frames addressed to its MAC address, the broadcast address and certain enabled multicast addresses.)
So why do you want to disable promiscuous mode? (I suspect you don't correctly understand promiscuous mode. See description of promiscuous mode in the description of the addm parameter in the ifconfig man page at http://www.freebsd.org/cgi/man.cgi?query=ifconfig&apropos=0&sektion=0&manpath=FreeBSD+9.1-RELEASE&arch=default&format=html )
Sorry, I was not clear: I'm talking about capturing in a wireless network.
It's been a while since I played around with wifi at the base level but I seem to recall that the hardware cannot be in both hostap mode and monitor mode (or any other mode). Since pfSense does not allow you to select anything but hostap, infrastructure and ad-hoc you not be able to this, at least not easily.
If you are using virtual APs the interface will need to be in promiscuous mode since each AP has its own MAC. The card must respond to packets addressed to the virtual MAC.Steve
That's correct, a WNIC can't function as an AP and monitor at the same time. By executing 'ifconfig ath0_wlan0 monitor' the wireless network is no longer available, so it is not functioning as an AP anymore. However, ifconfig shows that it's still in <hostap>mode, but then with a MONITOR flag.
ath0_wlan0: flags=48943 <up,broadcast,running,promisc,simplex,multicast,monitor>metric 0 mtu 1500 ether 90:a4:de:c7:55:57 inet6 fe80::92a4:deff:fec7:5557%ath0_wlan0 prefixlen 64 scopeid 0x9 nd6 options=3 <performnud,accept_rtadv>media: IEEE 802.11 Wireless Ethernet autoselect mode 11b <hostap></hostap></performnud,accept_rtadv></up,broadcast,running,promisc,simplex,multicast,monitor>@cmb:
It looks like you're bridging, which requires promiscuous mode to function.
Aha! Indeed, there's a bridge between vr0, vr2 and ath0_wlan0. I'll try removing it from there.</hostap>
-
I must be missing something.
Is monitor mode incompatible in some way with promiscuous mode?
It seems to me that monitor mode either implies promiscuous (NIC accepts all receive frames) mode (in which case setting monitor and promiscuous mode shouldn't be troublesome) or monitor mode means set the NIC into "read only" mode (no "talking"). If the second interpretation is correct then extrapolating from the wired NIC case, it would seem monitor mode on its own would not be very useful because the NIC wouldn't see any frames addressed to its MAC address (since it doesn't talk so doesn't announce its presence).
A search of the FreeBSD ath, ath_pci, ifconfig and wlan man pages for monitor gave me no grounds for believing monitor mode would cause a WiFi NIC to accept all frames, regardless of destination MAC address. But maybe those documents assume a greater knowledge of the details of 802.11 than I possess.
-
Here's what I presume to be the real difference between these modes: http://superuser.com/a/285965/209376
I'm not sure whether they conflict, but at the moment it's my best guess.
-
Here's what I presume to be the real difference between these modes: http://superuser.com/a/285965/209376
Thanks for the link. That web page seems oriented to Linux (though the particular question is about Windows 7). Linux information might not be applicable to FreeBSD, the base operating system of pfSense.
I'm not sure whether they conflict, but at the moment it's my best guess.
You are attempting a capture and not seeing what you expect and looking for the reason? I have done packet capture (tcpdump) on a WiFi interface on one of my pfSense boxes and seen some type of POL frames. But that was with with the WIFi interface acting as an AP or WiFi client. I have not tried monitor mode on a pfSense box.
-
I confess all my wifi tinkering was using Linux in one form or another.
My thanks also for the link. That sums up what I what thinking better than I could have done.
I fairly sure that monitor mode is a feature of the chipset so I would imagine it exists under any OS. It may not be implemented or usable under FreeBSD, I'd be surprised if it wasn't though.
In my experience you only need to use monitor mode for some the more shady activities in world of wifi. ;) Not that all of them are necessarily bad. If you want to know what wifi there is in your area, what channel is least congested, you can't beat running kismet for a few hours. That uses monitor mode. What are you trying to do?Steve
-
Well, this is going offtopic, hopefully that's not an issue.. Note that I already had a topic about capturing frames which didn't quite get the attention like this one.
My purpose of using monitor mode is to measure signal strength. Monitoring is certainly kind of shady, but it's for a university research project I'm working on. And science is never shady! ::)
Examples of how I attempt to do this with tcpdump are given here and here. I tried the former approach but haven't yet had the time to do the latter. Here's an example tracefile which contains the exact type of output that I'm looking for.
edit: It is all geared towards Linux indeed. But like you said, I'm doubtful that FreeBSD is incapable of doing the same thing. If anything it must be the FreeBSD Atheros driver not supporting Monitor, or the Promisc mode on the interface is actually causing problems. I'll have time in the evening to try and see if the latter is the case.
-
If you are using pfSense as a base for this I would probably start with the atheros inerface unassigned. Otherwise you will be fighting the system as it tries to put card in hostap mode (or whatever you've selected).
Sounds like an interesting project anyway. :)Steve
-
The horror when you find out the solution has been waiting under your nose the whole time. :-\
Basically I had to combine the methods from both approaches in my previous post. That is, cloning the ath0 interface, putting that in monitor mode, and then running tcpdump with the -y ieee802_11_radio argument.
$ ifconfig wlan create wlandev ath0 $ ifconfig wlan1 down $ ifconfig wlan1 monitor $ ifconfig wlan1 channel 4 #monitor desired channel $ ifconfig wlan1 up $ ifconfig wlan1 wlan1: flags=48843 <up,broadcast,running,simplex,multicast,monitor>metric 0 mtu 1500 ether 90:a4:de:c7:55:57 inet6 fe80::92a4:deff:fec7:5557%wlan1 prefixlen 64 scopeid 0xc nd6 options=3 <performnud,accept_rtadv>media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 4 (2427 MHz 11g) regdomain ETSI country NL ecm authmode OPEN privacy OFF txpower 30 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode OFF wme burst $ tcpdump -y ieee802_11_radio -n -e -tttt -vvv -i wlan1 -s 0</performnud,accept_rtadv></up,broadcast,running,simplex,multicast,monitor>Beacon frames and probe requests/responses all over the place. The topic question isn't solved, but at least my problem is :) Thanks for thinking along guys, really helped me get a better perspective on things and to reach the idea of combining said approaches.
-
If someone will find this topic I've got one remark.
Initializing the monitor mode in 'separate lines' (like in the post above) didn't work for me.
I had to do it in one line with:ifconfig wlan create wlandev ath0 wlanmode monitor ifconfig wlan1 upInterface options for reference:
wlan1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500 ether 00:80:48:64:63:57 inet6 fe80::280:48ff:fe64:6357%wlan1 prefixlen 64 scopeid 0xb nd6 options=43 <performnud,accept_rtadv>media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <monitor> status: running ssid "" channel 11 (2462 MHz 11g) bssid 00:80:48:64:63:57 regdomain ETSI country NL ecm authmode OPEN privacy OFF txpower 30 scanvalid 60 protmode OFF wme burst</monitor></performnud,accept_rtadv></up,broadcast,running,promisc,simplex,multicast>
