Date: Tue, 19 Jan 2016 20:17:46 +0100 From: "O. Hartmann" <ohartman@zedat.fu-berlin.de> To: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: network/ath: on CURRENT no connections possible on ath-based AP Message-ID: <20160119201746.13674c54.ohartman@zedat.fu-berlin.de>
next in thread | raw e-mail | index | archive | help
--Sig_/KN593u58KfbJHwrsa_Sd8Y3
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Running hostapd and a Atheros based AP on recent CURRENT (FreeBSD 11.0-CURR=
ENT #8
r294329: Tue Jan 19 18:23:20 CET 2016 amd64), clients do not connect anymor=
e 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 pc=
i1
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=3D8943<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=20
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=20
[...]
On some earlier dmesg outputs, I see the line=20
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!) thei=
r IP via
isc-dhcp (isc-dhcp43-server-4.3.3P1_1), then they die or can not access th=
e network any
further.
Has there been a change recently?
Kind regards,
Oliver
--Sig_/KN593u58KfbJHwrsa_Sd8Y3
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWnovaAAoJEOgBcD7A/5N89FQH/3vqojuoVsoV21Y6Xw2SOGfM
K70JsTvoXfVQL3Tu2yvkNKNtFn9SwGpxvqGrlpE59fVeTU7+b5t8iZ8otzXItmMQ
2ZcYR4fRep+O6XmdgUevHsyH4OzUZHU5jImuPLrMYcjjbT9Bwh7mNQLQTAQpvsMc
om14s+zLNZaO3dmU/M189ZvuUkly680Cr/btGghS5JyM0ij+OPeDgceRx36+3ow8
tWMgJNeEDtHHe6HRhlCR0ZQaQzM/KmHPyhSVf3sl/fkwbRexneM86CQTa1oIhcxO
IltDPq3W5c7WuO7sYsZg01+oUElV6BPgCHFv/QxVxX5EqFc8Afpf/oQ7vZrlABQ=
=RRHo
-----END PGP SIGNATURE-----
--Sig_/KN593u58KfbJHwrsa_Sd8Y3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160119201746.13674c54.ohartman>