Depending on whether this is after all a driver issue, it might need to be retitled. I have a home router / access point running two AR9380 cards. I have set them up like this (two configs, hostapd started manually with both): bridge=bridge0 interface=wlan1 hw_mode=a channel=165 utf8_ssid=1 ssid2=XXX ieee80211n=1 wmm_enabled=1 auth_algs=1 wpa=2 wpa_key_mgmt=WPA-PSK rsn_pairwise=CCMP wpa_passphrase=XXX ht_capab=[HT40-] ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel bridge=bridge0 interface=wlan0 hw_mode=g channel=11 utf8_ssid=1 ssid2=XXX auth_algs=1 ieee80211n=1 wmm_enabled=1 wpa=2 wpa_key_mgmt=WPA-PSK rsn_pairwise=CCMP wpa_passphrase=XXX ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel However, some settings are not applied. Specifically, channel stays at 1 for both cards (meaning both will run at 2.4GhZ and I wanted one of them at 5GhZ). And 802.11n doesn't seem to be applied, only 802.11g works.
The cards are detected as: ath0@pci2:3:0:0: class=0x028000 rev=0x01 hdr=0x00 vendor=0x168c device=0x0030 subvendor=0x106b subdevice=0x009a vendor = 'Qualcomm Atheros' device = 'AR93xx Wireless Network Adapter' class = network ath1@pci2:4:0:0: class=0x028000 rev=0x01 hdr=0x00 vendor=0x168c device=0x0030 subvendor=0x106b subdevice=0x009a vendor = 'Qualcomm Atheros' device = 'AR93xx Wireless Network Adapter' class = network
I meant channel 1. Here's a printout from ifconfig: wlan1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=0 ether XXX groups: wlan ssid XXX channel 1 (2412 MHz 11g) bssid XXX regdomain 100 indoor ecm authmode WPA2/802.11i privacy MIXED deftxkey 2 AES-CCM 2:128-bit txpower 20 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs parent interface: ath1 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap> status: running nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> wlan0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=0 ether XXX groups: wlan ssid XXX channel 1 (2412 MHz 11g) bssid XXX regdomain 101 indoor ecm authmode WPA2/802.11i privacy MIXED deftxkey 2 AES-CCM 2:128-bit txpower 20 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs parent interface: ath0 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap> status: running nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
How do you create the wlan0 and wlan1 interfaces?
wlans_ath0="wlan0" create_args_wlan0="wlanmode hostap" wlans_ath0="wlan1" create_args_wlan1="wlanmode hostap" I now know why 802.11n doesn't work, it's just not in the GENERIC config. I fixed it in https://reviews.freebsd.org/D43549 But other parameters are still not respected.
Set hardware as it somehow is important in this case it seems. Add cy@ to Cc: I can reproduce the chan not being set on rtwn and a quick look around tells me start debugging around this line: ./ap/hostapd.c: if (hostapd_get_hw_features(iface)) { The workaround is probably to set and run it all from rc.conf for now.
I can reproduce it on rtwn(4) as well. I'll take this.
It affects ports/net/hostapd as well.
Tested with ports/net/hostap29 (the previous hostapd that was in base). It behaves with the same regression.
My TL-WN823N (RTL8192EU) will only do 2.4 GHz (https://www.tp-link.com/ca/home-networking/adapter/tl-wn823n/#specifications). My AR5B97 and AR9462 will also only do 2.4.
I will try to purchase one of these NICs.
The card arrived but it won't work with my laptop. Got my hands on an AR9462(AR5B22), no joy with PR/255337. (BTW, booting Windows 10 with the AR9462 resulted in a BSOD.)
My new TP-LINK AC1200 just arrived today. Testing hostapd with it I get: slippy# ifconfig wlan1 wlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=200001<RXCSUM,RXCSUM_IPV6> ether 18:a6:f7:17:26:2e inet6 fe80::1aa6:f7ff:fe17:262e%wlan1 prefixlen 64 scopeid 0x6 groups: wlan ssid Lotus_Pond channel 40 (5200 MHz 11a ht/40-) bssid 18:a6:f7:17:26:2e regdomain FCC country US authmode OPEN privacy OFF txpower 17 mcastrate 6 mgmtrate 6 scanvalid 60 ampdulimit 64k ampdudensity 16 shortgi -stbc -uapsd wme dtimperiod 1 -dfs parent interface: rtwn0 media: IEEE 802.11 Wireless Ethernet autoselect mode 11na <hostap> status: running nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> slippy# Indeed hostapd does work at 5.2 GHz. Could be an ath(4) problem? I'll continue to monitor but maybe bz or adrian can verify with the ath(4) driver?
Nevermind. Looking at the wrong interface.
Seeing this: Feb 25 16:55:44 slippy kernel: rtwn0: rtwn_tx_beacon_check: cannot push beacon i nto chip, error 60! Feb 25 16:55:44 slippy kernel: rtwn0: unable to push beacon into the chip, error 60 Feb 25 16:55:44 slippy kernel: rtwn0: rtwn_newstate: could not move to RUN state
(In reply to Cy Schubert from comment #14) Please open an rtwn bug for this. You likely have yet another weird hardware revision .. or whatever. We should sort that elsewhere...
As for where to start digging for hostap (independent on interface I think but I'll try to test with more the next days for you) see Comment #5 here. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276375#c5
(In reply to Bjoern A. Zeeb from comment #15) I'll hold off on this for a while as I become familiar with this new rtwn(4) device. The errors may have been me plugging in and unplugging the device. I don't see the messages since last reboot (updating to latest -current) this evening.
(In reply to Bjoern A. Zeeb from comment #16) I managed to get it working on channel 165. slippy# ifconfig wlan1 wlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=200001<RXCSUM,RXCSUM_IPV6> ether 18:a6:f7:17:26:2e inet 10.1.3.1 netmask 0xffffff00 broadcast 10.1.3.255 inet6 fe80::1aa6:f7ff:fe17:262e%wlan1 prefixlen 64 scopeid 0x6 groups: wlan ssid Lotus_Pond channel 165 (5825 MHz 11a) bssid 18:a6:f7:17:26:2e regdomain FCC country US authmode WPA1+WPA2/802.11i privacy MIXED deftxkey 2 AES-CCM 2:128-bit txpower 23 mcastrate 6 mgmtrate 6 scanvalid 60 wme dtimperiod 1 -dfs parent interface: rtwn0 media: IEEE 802.11 Wireless Ethernet autoselect mode 11a <hostap> status: running nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> slippy# My phone is on this network at 10.1.3.100 -- slippy being my FreeBSD laptop. Using kea to hand out dhcp IP addresses. slippy# ping -c 5 10.1.3.100 PING 10.1.3.100 (10.1.3.100): 56 data bytes 64 bytes from 10.1.3.100: icmp_seq=0 ttl=64 time=240.065 ms 64 bytes from 10.1.3.100: icmp_seq=1 ttl=64 time=48.195 ms 64 bytes from 10.1.3.100: icmp_seq=2 ttl=64 time=43.043 ms 64 bytes from 10.1.3.100: icmp_seq=3 ttl=64 time=200.041 ms 64 bytes from 10.1.3.100: icmp_seq=4 ttl=64 time=17.586 ms --- 10.1.3.100 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 17.586/109.786/240.065/91.507 ms slippy# One caveat. I had to manually set the channel on wlan1, using ifconfig wlan1 channel 165, prior to starting hostapd. I will need to determine whether hostapd fails to set the channel for the 5 GHz or for the 2.4 GHz as well. But I certainly can reproduce Piotr's problem when I do not set channel manually, using ifconfig wlan1 channel 165. But when issuing ifconfig wlan1 channel 165 before starting hostapd, it works well. I have three rtwn(4) devices (two 2.4 GHz devices and one 2.4/5 GHz device) here. I'll do some testing with all three devices to drill down to find out why hostapd does not set the channel. In the mean time we can instruct people to manually set the channel prior to starting hostapd.
Just to keep everyone in the loop, if (iface->freq) at line 2369 in hostapd.c is zero. Therefore it never sets the channel at line 2376.
Testing a 2.4 GHz rtwn(2), same behaviour. Regardless of the channel selected in the conf file the channel is always 1. If the channel is set manually using ifconfig, the interface will maintain the same channel after hostapd has started.
(In reply to Bjoern A. Zeeb from comment #5) My sleuthing has come to the same conclusion.
So that nobody wastes time chasing this, this is related to MLME.
Created attachment 248774 [details] Work around Linux MLME requirement. hostapd will only set the channel (frequency) when Linux MLME is configured. Enabling NEED_AP_MLME will result in numerous build errors due do Linux data structures and definitions not available under FreeBSD. The code to set the frequency from the selected channel is only within the NEED_AP_MLME code path because without MLME, hostapd_get_hw_features() is an inline that always returns -1 whereas with MLME hostapd_get_hw_features() will obtain hardware features from the kernel. Until such time we simply set the frequency as configured. I'll also add this same patch to two of the three ports (excluding the hostap29 port).
Created attachment 248775 [details] Work around Linux MLME requirement. The comment in the patch missed a couple of words that altered the complete meaning of the paragraph. Let's upload it again, this time with the correct comment.
Created attachment 248776 [details] Same but for ports. Same patch as base but for ports.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=84ed86380aeb566ffd8b957ba99c36ad345413ef commit 84ed86380aeb566ffd8b957ba99c36ad345413ef Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2024-02-27 03:34:09 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2024-03-04 16:40:58 +0000 hostapd: Work around lack of MLME support hostap MLME uses Linux data structures and definitions not available in FreeBSD. The ability for hostapd to select the frequency (channel) depends Linux MLME, though strictly it's not required. Work around the Linux MLME requirement to configure device frequency. The detailed description is: hostapd will only set the channel (frequency) when Linux MLME is configured. Enabling NEED_AP_MLME will result in numerous build errors due do Linux data structures and definitions not available under FreeBSD. The code to set the frequency from the selected channel is only within the NEED_AP_MLME code path because without MLME, hostapd_get_hw_features() is an inline that always returns -1 whereas with MLME hostapd_get_hw_features() will obtain hardware features from the kernel. Until such time we simply set the frequency as configured. PR: 276375 MFC after: 1 month contrib/wpa/src/ap/hostapd.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=2dc822b9e7c44abf61594cbc31379837bb35973d commit 2dc822b9e7c44abf61594cbc31379837bb35973d Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2024-02-27 04:27:50 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2024-03-04 16:44:36 +0000 net/hostapd*: Work around lack of MLME support hostap MLME uses Linux data structures and definitions not available in FreeBSD. The ability for hostapd to select the frequency (channel) depends Linux MLME, though strictly it's not required. Work around the Linux MLME requirement to configure device frequency. The detailed description is: hostapd will only set the channel (frequency) when Linux MLME is configured. Enabling NEED_AP_MLME will result in numerous build errors due do Linux data structures and definitions not available under FreeBSD. The code to set the frequency from the selected channel is only within the NEED_AP_MLME code path because without MLME, hostapd_get_hw_features() is an inline that always returns -1 whereas with MLME hostapd_get_hw_features() will obtain hardware features from the kernel. Until such time we simply set the frequency as configured. PR: 276375 MFH: 2024Q1 net/hostapd-devel/Makefile | 2 +- .../files/patch-src_ap_hostapd.c (new) | 31 ++++++++++++++++++++++ net/hostapd/Makefile | 2 +- net/hostapd/files/patch-src_ap_hostapd.c (new) | 31 ++++++++++++++++++++++ 4 files changed, 64 insertions(+), 2 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=beb5140a9d8f349866ef4ba8ada9d98faed2c770 commit beb5140a9d8f349866ef4ba8ada9d98faed2c770 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2024-02-27 03:34:09 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2024-04-03 00:28:45 +0000 hostapd: Work around lack of MLME support hostap MLME uses Linux data structures and definitions not available in FreeBSD. The ability for hostapd to select the frequency (channel) depends Linux MLME, though strictly it's not required. Work around the Linux MLME requirement to configure device frequency. The detailed description is: hostapd will only set the channel (frequency) when Linux MLME is configured. Enabling NEED_AP_MLME will result in numerous build errors due do Linux data structures and definitions not available under FreeBSD. The code to set the frequency from the selected channel is only within the NEED_AP_MLME code path because without MLME, hostapd_get_hw_features() is an inline that always returns -1 whereas with MLME hostapd_get_hw_features() will obtain hardware features from the kernel. Until such time we simply set the frequency as configured. PR: 276375 (cherry picked from commit 84ed86380aeb566ffd8b957ba99c36ad345413ef) contrib/wpa/src/ap/hostapd.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0fb7c4a38c8527156b1d1eedd072787602a13c69 commit 0fb7c4a38c8527156b1d1eedd072787602a13c69 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2024-02-27 03:34:09 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2024-04-03 00:29:13 +0000 hostapd: Work around lack of MLME support hostap MLME uses Linux data structures and definitions not available in FreeBSD. The ability for hostapd to select the frequency (channel) depends Linux MLME, though strictly it's not required. Work around the Linux MLME requirement to configure device frequency. The detailed description is: hostapd will only set the channel (frequency) when Linux MLME is configured. Enabling NEED_AP_MLME will result in numerous build errors due do Linux data structures and definitions not available under FreeBSD. The code to set the frequency from the selected channel is only within the NEED_AP_MLME code path because without MLME, hostapd_get_hw_features() is an inline that always returns -1 whereas with MLME hostapd_get_hw_features() will obtain hardware features from the kernel. Until such time we simply set the frequency as configured. PR: 276375 (cherry picked from commit 84ed86380aeb566ffd8b957ba99c36ad345413ef) contrib/wpa/src/ap/hostapd.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)