The "bssid" parameter to ifconfig does notwork as advertised with ath hardware: all wlan devices have the same MAC address(es) as their parent(s), whether or not the "bssid" keyword is used when they are created. I know I have used it successfully in the past but it may have been with a different (ath) card and I don't know what FreeBSD version it was so I can't be much help in determining when it stopped working (if indeed it ever did for this hardware). The machine in question currently has an AR9220 card: ath0: <Atheros 9220> mem 0xfebf0000-0xfebfffff irq 20 at device 5.0 on pci4 [ath] enabling AN_TOP2_FIXUP ath0: [HT] enabling HT modes ath0: [HT] 2 RX streams; 2 TX streams ath0: Enabling register serialisation ath0: AR9220 mac 128.2 RF5133 phy 13.0 ath0@pci0:4:5:0: class=0x028000 card=0x2096168c chip=0x0029168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR922X Wireless Network Adapter' How-To-Repeat: ifconfig wlan0 create wlandev ath0 wlanmode hostap bssid ifconfig wlan1 create wlandev ath0 wlanmode hostap bssid ifconfig ath0 ifconfig wlan0 ifconfig wlan1 notice that the MAC addresses of both vap's are identical to the parent device.
> The "bssid" parameter to ifconfig does notwork as advertised with ath > hardware: all wlan devices have the same MAC address(es) as their = parent(s), > whether or not the "bssid" keyword is used when they are created. I = know I > have used it successfully in the past but it may have been with a = different > (ath) card and I don't know what FreeBSD version it was so I can't be = much > help in determining when it stopped working (if indeed it ever did for = this > hardware). The machine in question currently has an AR9220 card: >=20 > ath0: <Atheros 9220> mem 0xfebf0000-0xfebfffff irq 20 at device 5.0 on = pci4 > [ath] enabling AN_TOP2_FIXUP > ath0: [HT] enabling HT modes > ath0: [HT] 2 RX streams; 2 TX streams > ath0: Enabling register serialisation > ath0: AR9220 mac 128.2 RF5133 phy 13.0 >=20 > ath0@pci0:4:5:0: class=3D0x028000 card=3D0x2096168c = chip=3D0x0029168c rev=3D0x01 hdr=3D0x00 > vendor =3D 'Atheros Communications Inc.' > device =3D 'AR922X Wireless Network Adapter' Was looking for something to do today and looked into this. It appears = that the ath driver for the 9280 chipset (which is what your card has) = does not set the halBssIdMaskSupport capability. Since this variable is = not set the behavior you experience is to be expected. I'm not familiar = enough with the hardware to know for sure whether or not it supports = this feature but if it does I would imagine it would be as simple as = adding the following line to sys/dev/ath/ath_hal/ar9002/ar9280_attach.c: --- ar9280_attach.c 2012-01-02 20:26:54.000000000 -0700 +++ ar9280_attach_new.c 2012-03-12 20:50:58.000000000 -0700 @@ -841,6 +841,7 @@ pCap->halRxStbcSupport =3D 1; pCap->halTxStbcSupport =3D 1; pCap->halEnhancedDfsSupport =3D AH_TRUE; + pCap->halBssIdMaskSupport =3D AH_TRUE; =20 return AH_TRUE; } If I'm way off base here someone let me know, this is my first dive into = these drivers. -Erick
I remember changing one email or to with Adrian Chad about some time ago "MAC spoofing" (I want to use bhyve with wlan0+tap0 in bridge, and this laptop only comes with the wifi card, no Ethernet...) and it wasn't supported at the time, so I wonder if this is by design? Mine does the same: ath0@pci0:2:0:0: class=0x028000 card=0xe052105b chip=0x0034168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR9462 Wireless Network Adapter' class = network ath0: <Atheros AR946x/AR948x> mem 0xc0400000-0xc047ffff irq 19 at device 0.0 on pci2 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9460 mac 640.2 RF5110 phy 1070.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 I'm just wondering if the driver created wlanX with different MAC address, the driver is still (I'm assuming sorry if I'm wrong) not ready to deal with that... and so things would work properly anyway? Sorry if I'm saying total none-sense.
(In reply to miguelmclara from comment #2) *"I remember exchanging one email or two"*
Hi, by default net80211 doesn't change the MAC address for each vap. The bssid parameter should be doing that. IT did work when I checked it last. Please try on -HEAD. :)
Created attachment 158429 [details] sample output Hi, I just stumbled in this problem with a 10.1 nanobsd image I use as home router. (it's a 10.1-RELEASE with a few selected commits from head mered in locally, but mostly unrelated) I also tested it on my laptop (with head). I've attached a capture of a session showing the problem on the laptop, with this device: ath0: <Atheros 9280> mem 0xf0500000-0xf050ffff irq 17 at device 0.0 on pci2 ath0: [HT] enabling HT modes ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9280 mac 128.2 RF5133 phy 13.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 the 10.1 nanobsd image has this hardware: ath0: <Atheros 5212> mem 0xe0080000-0xe008ffff irq 9 at device 12.0 on pci0 ath0: AR5212 mac 5.9 RF5112 phy 4.3 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0036 Am I missing something or doing something wrong?
The "bssid" parameter does indeed work on 10-STABLE and 11-CURRENT (and probably earlier?). I do seem to recall that the order of ifconfig parameters makes a difference, though. Since opening this ticket I have changed my rc.conf to have "bssid" at the beginning of the relevant lines instead of at the end and it has been working fine for some time. Excerpt from working rc.conf: wlans_ath1="wlan1 wlan3" create_args_wlan1="bssid wlanmode hostap mode 11g channel 1:ht/40+" create_args_wlan3="bssid wlanmode hostap mode 11g channel 1:ht/40+" Excerpt from ifconfig output: wlan1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 00:1b:b1:5d:XX:YY wlan3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 06:1b:b1:5d:XX:YY Note the difference in the first octet of the MAC address: '00' for wlan1 and '06' for wlan3. AFAIK this bug can be closed.
(In reply to John Nielsen from comment #6) Thanks for your suggestion. I'll test this soon and report back.
(In reply to Guido Falsi from comment #7) I performed further tests as you suggested on 10.2 and everything worked out fine this time. So, I agree this bug report can be closed now.
I just noticed this bug report is still open, but I think the problem is solved since FreeBSD 10.2. I'm going to close it in a few days if nobody reports the problem is still present on recent versions. Thanks.
Feedback indicates problem is solved at least on FreeBSD 10.2 and newer. Thanks.