Re: network/ath: on CURRENT no connections possible on ath-based AP

Theres been nothing in the ath code that I can think of that'd do this.

Can you get me "works" and "doesn't work" revisions?

thanks,


-a


On 19 January 2016 at 11:17, O. Hartmann <ohartman_at_zedat.fu-berlin.de> wrote:
> Running hostapd and a Atheros based AP on recent CURRENT (FreeBSD 11.0-CURRENT #8
> r294329: Tue Jan 19 18:23:20 CET 2016 amd64), clients do not connect anymore to that
> specific AP. They did a week or two ago (mobile phones, several notebooks).
>
> The WiFi adaptor is this one (dmesg):
>
> [...]
> ath0: <Atheros AR938x> mem 0xf7e00000-0xf7e1ffff irq 16 at device 0.0 on pci1
> ar9300_attach: calling ar9300_hw_attach
> ar9300_hw_attach: calling ar9300_eeprom_attach
> ar9300_flash_map: unimplemented for now
> Restoring Cal data from DRAM
> Restoring Cal data from EEPROM
> ar9300_hw_attach: ar9300_eeprom_attach returned 0
> 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] 3 RX streams; 3 TX streams
> ath0: AR9380 mac 448.3 RF5110 phy 3276.12
> ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000
> [...]
>
> and from ifconfig:
>
> [...]
> wlan0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         ether xx:xx:xx:xx:xx:xx
>         inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
>         media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>
>         status: running
>         ssid Berghof channel 10 (2457 MHz 11g) bssid xx:xx:xx:xx:xx:xx
>         regdomain ETSI country DE indoor ecm authmode WPA2/802.11i
>         privacy MIXED deftxkey 2 AES-CCM 2:128-bit AES-CCM 3:128-bit
>         txpower 30 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs
>         groups: wlan
> [...]
>
> On some earlier dmesg outputs, I see the line
>
> ath0: AR9380 mac 448.3 RF5110 phy 2457.9
>
> instead of the most recent
>
> ath0: AR9380 mac 448.3 RF5110 phy 3276.12
>
> I do not see any strange behaviour until clients fetch (successfully!) their IP via
> isc-dhcp (isc-dhcp43-server-4.3.3P1_1), then they die or can not access  the network any
> further.
>
> Has there been a change recently?
>
> Kind regards,
>
> Oliver