Modify

Opened 3 years ago

Last modified 3 years ago

#18151 new defect

Hostapd hangup with barrier breaker

Reported by: owrtbug Owned by: developers
Priority: normal Milestone:
Component: kernel Version: Barrier Breaker 14.07
Keywords: Cc:

Description

We use D-Link DIR-825 Firmware Revision C1 with current Barrier Breaker. Hostapd is configured for 802.1x authentication with a freeradius server.

Sometimes, the hostaps sems to hang up an even if the authentication itself still seems to work (client tells he is connected to the network), DHCP and other traffic isn't passing through. Everytime this happens, the following message is displayed in dmesg:

[28931.920000] ------------[ cut here ]------------
[28931.930000] WARNING: at /BB/build/ar71xx/generic/build_dir/target-mips_34kc_uClibc-0.9.33.2/
linux-ar71xx_generic/compat-wireless-014-05-22/net/mac80211/iface.c:812 
ieee80211_del_virtual_monitor+0x2c4/0x8b8 [mac80211]()
[28931.950000] Modules linked in: ath9k ath9k_common pppoe ppp_async iptable_nat 
ath9k_hw ath pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211 ipt_MASQUERADE 
cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit 
xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_nat_irc 
nf_nat_ftp nf_nat nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp iptable_raw 
iptable_mangle iptable_filter ipt_REJECT ip_tables crc_ccitt compat ledtrig_usbdev 
ip6t_REJECT ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables 
nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher 
ehci_platform ehci_hcd gpio_button_hotplug us
bcore nls_base usb_common
[28932.010000] CPU: 0 PID: 1112 Comm: hostapd Not tainted 3.10.49 #3
[28932.020000] Stack : 00000000 00000000 00000000 00000000 803bce76 00000035 879133e8 871caa98
[28932.020000] 	  802f5b44 8033f9a3 00000458 803b3a00 879133e8 871caa98 871caab4 00000001
[28932.020000] 	  00000008 80290d44 00000003 801f39b0 871ca8a4 871caa98 802f71d4 86e939fc
[28932.020000] 	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[28932.020000] 	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 86e93988
[28932.020000] 	  ...
[28932.050000] Call Trace:
[28932.060000] [<80235a38>] show_stack+0x48/0x70
[28932.060000] [<802a06ec>] warn_slowpath_common+0x78/0xa8
[28932.070000] [<802a07a4>] warn_slowpath_null+0x18/0x24
[28932.070000] [<871915b0>] ieee80211_del_virtual_monitor+0x2c4/0x8b8 [mac80
211]
[28932.080000] [<801a4730>] local_bh_enable+0x90/0xac
[28932.080000] 
[28932.090000] ---[ end trace a76fafb8169f02e6 ]---

Killing and restarting the hostapd process helps when encountering this situation. A network or router restart is not necessary.

How can I help debug this to make the 802.1x authentication more reliable.

Attachments (0)

Change History (6)

comment:1 Changed 3 years ago by bittorf@…

please let hostapd produce crashlogs:

sed -i 's/hostapd -P/ulimit -c unlimited; &/' '/lib/wifi/hostapd.sh'

after a crash you should have a file in /tmp/*.core and
get a backtrace with remote-gdb on your build-server:

scripts/remote-gdb $corefile stagingdir/.../path/to/binary
(e.g. staging_dir/target-mips_34kc_uClibc-0.9.33.2/root-ar71xx/usr/sbin/wpad)

comment:2 Changed 3 years ago by owrtbug

Hostapd (which is located in /lib/netifd/hostapd.sh) is not crashing completely. It keeps running
so I'm sorry I can't provide a core file. After running the daemon with "-dd" flags it can be seen
that the trouble starts after the first client deauthenticates. One can close the connection at client
to trigger this.

wlan0: STA 00:24:d7:6c:e0:2c RADIUS: Received RADIUS packet matched with a pending 
request, round trip time 0.01 sec
wlan0: STA MAC RADIUS: VLAN ID 711
wlan0: STA MAC IEEE 802.11: authentication OK (open system)
         -> same with wpa2, this test has been done with no encryption

wlan0: STA MAC MLME: MLME-AUTHENTICATE.indication(MAC, OPEN_SYSTEM)
wlan0: STA MAC MLME: MLME-DELETEKEYS.request(MAC)
wlan0: STA MAC IEEE 802.11: authenticated
wlan0: STA MAC IEEE 802.11: association OK (aid 1)
wlan0: STA MAC IEEE 802.11: associated (aid 1)
wlan0: STA MAC MLME: MLME-ASSOCIATE.indication(MAC)
wlan0: STA MAC MLME: MLME-DELETEKEYS.request(MAC)
wlan0: STA MAC IEEE 802.11: added new dynamic VLAN interface 'wlanxxx0.711'
wlan0: STA MAC IEEE 802.11: binding station to interface 'wlanxxx0.711'
wlan0: STA MAC WPA: event 1 notification
wlan0: STA MAC IEEE 802.1X: start authentication
wlan0: STA MAC WPA: start authentication
wlan0: STA MAC IEEE 802.1X: unauthorizing port
wlan0: CTRL-EVENT-EAP-STARTED MAC
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
wlan0: STA MAC IEEE 802.1X: Sending EAP Packet (identifier 245)
VLAN: vlan_add: ADD_VLAN_CMD failed for eth0: File exists
VLAN: vlan_add: ADD_VLAN_CMD failed for eth0: File exists
VLAN: vlan_add: ADD_VLAN_CMD failed for eth0: File exists

Later we see these error messages

VLAN: br_addif: Failure determining interface index for 'wlanxxx0.711'
VLAN: ifconfig_helper: ioctl(SIOCGIFFLAGS) failed for interface wlanxxx0.711: No such device
VLAN: br_delif: Failure determining interface index for 'wlanxxx0.711'

Indeed, the interfaces are still on the bridge:

breth0.711		8000.e894f6b17200	no		eth0.711
							wlanxxx0.711

At this state, no dhcp and no other packages are passing through the bridge. If we kill hostapd (it
is the hostapd package, not wpad) und restart it, it is fixed for some time. The same issue can be
seen of a TL-WA901ND, so it doesn't seem to be a hardware dependent issue. We have the same problem
with Attitude Adjustment 12.09.

Any ideas?

comment:3 Changed 3 years ago by owrtbug

Additional information: this happens when using multiple SSIDs.

comment:4 Changed 3 years ago by owrtbug

With the following configuration change the problem did disappear: when using multipe ssids and dynamic vlan assignment, make sure you habe every possible device that can be generated by your hostapd.vlan files in the /etc/network/interfaces configuration file.

Without this, the connection might work once but after a client disconnects you're in trouble. It can happen later but AFAICS it behaves stable after adding every dynamic added interface to the network configuration.

comment:5 Changed 3 years ago by anonymous

owrtbug, can you clarify what you mean by "make sure you have every possible device that can be generated by your hostapd.vlan files in the /etc/network/interfaces configuration file?"

I am hitting the same issue (same exact stack trace), and also running Barrier Breaker, but I am confused because I don't have a /etc/network/interfaces file. Any other ideas on a workaround?

comment:6 Changed 3 years ago by anonymous

Bump - any update on this? Anyone have any inisight on a fix or workaround? I still see this issue on Chaos Calmer RC3.

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.