Why does ath(4) suck, and what else to buy?
Hey, I'm running this small -CURRENT box as router/AP and it has a miniPCI ath(4) card that typically works fine, it only reports the occasional ath0: stuck beacon; resetting (bmiss count 4) not sure if that is problematic, the wifi used to work fine. If that message is harmless, maybe it should not be printed. But that's not what I'm here for. I've tried setting up a 2nd wlan device and run hostapd on it for a guest SSID for house guests, etc. So I created wlan2 next to wlan0, ran an exact copy of the hostapd.conf (except different SSID and PSK) and that made lots of phones/tablets have trouble connecting or staying connected (wlan2 is bridged to the same bridge as wlan0 and the wired interfaces, so DHCP/DNS/routes are unlikely to be the problem). It looks like this: ath0: Atheros 9280 mem 0xe0a0-0xe0a0 irq 17 at device 0.0 on pci4 ath0: AR9280 mac 128.2 RF5133 phy 13.0 ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0 /etc/rc.conf: cloned_interfaces=bridge0 autobridge_interfaces=bridge0 autobridge_bridge0=port* wlan0 wlan2 wlans_ath0=wlan0 wlan2 create_args_wlan0=wlanmode hostap country DE authmode wpa ifconfig_wlan0=ssid COYOTE mode 11g pureg up create_args_wlan2=wlanmode hostap country DE authmode wpa ifconfig_wlan2=ssid COYOTE_GUEST mode 11g pureg up Haven't rebooted, so I've brought up wlan2 by hand: root@coyote:~# ifconfig wlan2 create wlandev ath0 wlanmode hostap country DE authmode wpa ifconfig: SIOCS80211: Device busy Exit 1 root@coyote:~# ifconfig wlan2 wlan2: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 68:a3:c4:51:44:99 inet6 fe80::6aa3:c4ff:fe51:4499%wlan2 prefixlen 64 tentative scopeid 0xd nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running ssid COYOTE_GUEST channel 8 (2447 MHz 11g) bssid 68:a3:c4:51:44:99 regdomain ETSI country DE indoor ecm authmode 802.1x privacy MIXED deftxkey UNDEF txpower 30 scanvalid 60 pureg protmode CTS wme burst dtimperiod 1 -dfs and it also magically got added to bridge0. root@coyote:~# /etc/rc.d/hostapd start wlan2 Starting hostapd. Configuration file: /etc/hostapd-wlan2.conf Using interface wlan2 with hwaddr 68:a3:c4:51:44:99 and ssid COYOTE_GUEST root@coyote:~# egrep -v '^#|^$|passphrase' /etc/hostapd-wlan2.conf interface=wlan2 driver=bsd logger_syslog=-1 logger_syslog_level=3 logger_stdout=-1 logger_stdout_level=2 debug=1 dump_file=/tmp/hostapd-wlan2.dump ctrl_interface=/var/run/hostapd-wlan2 ctrl_interface_group=wheel ssid=COYOTE_GUEST country_code=DE hw_mode=g macaddr_acl=0 auth_algs=1 wme_enabled=1 wpa=2 wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP and that's when the trouble starts to appear, dmesg now get's funny messages like: wlan2: Ethernet address: 68:a3:c4:51:44:99 wlan2: promiscuous mode enabled ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 0) ath0: ath_transmit: sc_inreset_cnt 0; bailing ath0: ath_tx_should_swq_frame: 50:46:5d:21:16:df: Node is asleep; sending mgmt (type=0, subtype=176) ath0: ath_tx_should_swq_frame: 38:e7:d8:69:c0:6e: Node is asleep; sending mgmt (type=0, subtype=176) ath0: ath_tx_should_swq_frame: b4:07:f9:e8:8f:8e: Node is asleep; sending mgmt (type=0, subtype=176) ath0: ath_node_recv_pspoll: 38:e7:d8:69:c0:6e: not in powersave? ath0: ath_tx_node_wakeup: an=0xfe0126489000: node was already awake ath0: ath_node_recv_pspoll: b4:07:f9:e8:8f:8e: not in powersave? ath0: ath_tx_node_wakeup: an=0xfe001e413000: node was already awake ath0: ath_node_recv_pspoll: b4:07:f9:e8:8f:8e: not in powersave? ath0: ath_node_recv_pspoll: b4:07:f9:e8:8f:8e: not in powersave? ath0: ath_node_recv_pspoll: b4:07:f9:e8:8f:8e: not in powersave? ath0: ath_tx_node_wakeup: an=0xfe0088add000: node was already awake Looking at some Android devices, they see that SSID as Secured with WEP, so no WPA2 :/ An oldish HTC Desire won't even see that SSID. Neither will a Ubuntu laptop. Can someone unstupid me? Do I need a wlanbssid override for wlan2? Now that it is in this state, the first devices fail to re-authenticate (on wlan0) with this AP. Guess I'll tear down wlan2 again. The second part of my question is related to buying recommendations for 5GHz USB wlan fobs that work solid as an AP (and virtual AP) under FreeBSD. Not all of my equipment can to 5GHz, so I need a dual-band solution (with VAPs for the 2.4GHz band). What do people use around here, what works solidly? Cheers, Uli ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Why does ath(4) suck, and what else to buy?
On Oct 16, 2013, at 11:29 AM, Ulrich Spörlein uspoerl...@gmail.com wrote: Hey, I'm running this small -CURRENT box as router/AP and it has a miniPCI ath(4) card that typically works fine, it only reports the occasional ath0: stuck beacon; resetting (bmiss count 4) not sure if that is problematic, the wifi used to work fine. If that message is harmless, maybe it should not be printed. But that's not what I'm here for. I've tried setting up a 2nd wlan device and run hostapd on it for a guest SSID for house guests, etc. So I created wlan2 next to wlan0, ran an exact copy of the hostapd.conf (except different SSID and PSK) and that made lots of phones/tablets have trouble connecting or staying connected (wlan2 is bridged to the same bridge as wlan0 and the wired interfaces, so DHCP/DNS/routes are unlikely to be the problem). It looks like this: ath0: Atheros 9280 mem 0xe0a0-0xe0a0 irq 17 at device 0.0 on pci4 ath0: AR9280 mac 128.2 RF5133 phy 13.0 ath0: 2GHz radio: 0x; 5GHz radio: 0x00c0 /etc/rc.conf: cloned_interfaces=bridge0 autobridge_interfaces=bridge0 autobridge_bridge0=port* wlan0 wlan2 wlans_ath0=wlan0 wlan2 create_args_wlan0=wlanmode hostap country DE authmode wpa ifconfig_wlan0=ssid COYOTE mode 11g pureg up create_args_wlan2=wlanmode hostap country DE authmode wpa ifconfig_wlan2=ssid COYOTE_GUEST mode 11g pureg up Haven't rebooted, so I've brought up wlan2 by hand: root@coyote:~# ifconfig wlan2 create wlandev ath0 wlanmode hostap country DE authmode wpa ifconfig: SIOCS80211: Device busy Exit 1 root@coyote:~# ifconfig wlan2 wlan2: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 68:a3:c4:51:44:99 inet6 fe80::6aa3:c4ff:fe51:4499%wlan2 prefixlen 64 tentative scopeid 0xd nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running ssid COYOTE_GUEST channel 8 (2447 MHz 11g) bssid 68:a3:c4:51:44:99 regdomain ETSI country DE indoor ecm authmode 802.1x privacy MIXED deftxkey UNDEF txpower 30 scanvalid 60 pureg protmode CTS wme burst dtimperiod 1 -dfs and it also magically got added to bridge0. root@coyote:~# /etc/rc.d/hostapd start wlan2 Starting hostapd. Configuration file: /etc/hostapd-wlan2.conf Using interface wlan2 with hwaddr 68:a3:c4:51:44:99 and ssid COYOTE_GUEST root@coyote:~# egrep -v '^#|^$|passphrase' /etc/hostapd-wlan2.conf interface=wlan2 driver=bsd logger_syslog=-1 logger_syslog_level=3 logger_stdout=-1 logger_stdout_level=2 debug=1 dump_file=/tmp/hostapd-wlan2.dump ctrl_interface=/var/run/hostapd-wlan2 ctrl_interface_group=wheel ssid=COYOTE_GUEST country_code=DE hw_mode=g macaddr_acl=0 auth_algs=1 wme_enabled=1 wpa=2 wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP and that's when the trouble starts to appear, dmesg now get's funny messages like: wlan2: Ethernet address: 68:a3:c4:51:44:99 wlan2: promiscuous mode enabled ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 0) ath0: ath_transmit: sc_inreset_cnt 0; bailing ath0: ath_tx_should_swq_frame: 50:46:5d:21:16:df: Node is asleep; sending mgmt (type=0, subtype=176) ath0: ath_tx_should_swq_frame: 38:e7:d8:69:c0:6e: Node is asleep; sending mgmt (type=0, subtype=176) ath0: ath_tx_should_swq_frame: b4:07:f9:e8:8f:8e: Node is asleep; sending mgmt (type=0, subtype=176) ath0: ath_node_recv_pspoll: 38:e7:d8:69:c0:6e: not in powersave? ath0: ath_tx_node_wakeup: an=0xfe0126489000: node was already awake ath0: ath_node_recv_pspoll: b4:07:f9:e8:8f:8e: not in powersave? ath0: ath_tx_node_wakeup: an=0xfe001e413000: node was already awake ath0: ath_node_recv_pspoll: b4:07:f9:e8:8f:8e: not in powersave? ath0: ath_node_recv_pspoll: b4:07:f9:e8:8f:8e: not in powersave? ath0: ath_node_recv_pspoll: b4:07:f9:e8:8f:8e: not in powersave? ath0: ath_tx_node_wakeup: an=0xfe0088add000: node was already awake Looking at some Android devices, they see that SSID as Secured with WEP, so no WPA2 :/ An oldish HTC Desire won't even see that SSID. Neither will a Ubuntu laptop. Can someone unstupid me? Do I need a wlanbssid override for wlan2? Now that it is in this state, the first devices fail to re-authenticate (on wlan0) with this AP. Guess I'll tear down wlan2 again. Do wlan0 and wlan2 have different MAC addresses? They need to. You could try adding the bssid flag to create_args_wlan2; that's supposed to make a unique MAC for you based on the hardware's real MAC. However last time I tried it (it's been a while) with my hardware it didn't work. So alternatively, you can add wlanaddr aa:bb:cc:dd:ee:ff to create_args_wlan2 (substituting a better MAC, of course). The second part of my question is related to buying recommendations for 5GHz USB wlan fobs that work solid as an AP (and virtual AP) under FreeBSD. Not
Re: AR934x initial support is now in the tree
The AR9271 is a USB-connected AR9285, for all intents and purposes. So it would use ath(4), if ath(4) had the required USB glue. Sorry. -adrian NetBSD-current seems to support AR9271, so maybe the required USB glue is not too far away? I haven't set it up yet, so can't see if it really works. So far, I use NetBSD-current amd64 with subversion built from pkgsrc to checkout and update FreeBSD source tree. NetBSD-current amd64 works with Realtek 8111E Ethernet on MSI Z77 MPOWER motherboard, while FreeBSD fails to connect. Otherwise, I can try to set up wifi through rsu or ndis, or see if ndis can work with Realtek 8111E Ethernet. Tom ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: AR934x initial support is now in the tree
oh, it's the athn port from openbsd. Sure, if someone ports the USB glue from that over, but glues it into our ath driver and ath_hal code, I'll commit it. The only bits are: * usb probe/attach * usb command send/receive * basic register read/write ops * HTC commands (new station, del station, rate control setup, etc.) if someone gets the first three done I'll help massage the rest of the ath driver to work with the USB nics. But, you should start on an AR7010 NIC as the AR9271 requires USB _AND_ HAL changes. I don't mind porting the HAL changes over (there aren't many) but I'd rather have the USB bits working before I try that. -adrian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
