Client associated, RADIUS accounting started but no connectivity (occasionally).

[kgara]

Hi. I am using bpi-r1 (lambo-r1) with rtl871.
Occasionally (once in several days) I face the problem that clients (any one of 2 Android phones or Mac mini, some guests devices with equal probability) are unable to connect to SSID after "obtaining ip address" step. See no DHCP requests on server side (dhcp daemon on the same bpi-r1). Setting static ip helps to connect to SSID, yet no other ip interaction between client and bpi possible (no pings, even no arp entries).
In logs of hostapd (and I believe I made maximum verbose) everything looks fine, at least as usual connection
"Problematic connection" hostapd logs:

Jul 27 08:02:24 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d IEEE 802.11: associated
Jul 27 08:02:24 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: event 1 notification
Jul 27 08:02:24 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: start authentication
Jul 27 08:02:24 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d IEEE 802.1X: unauthorizing port
Jul 27 08:02:24 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: sending 1/4 msg of 4-Way Handshake
Jul 27 08:02:24 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: received EAPOL-Key frame (2/4 Pairwise)
Jul 27 08:02:24 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: sending 3/4 msg of 4-Way Handshake
Jul 27 08:02:24 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: received EAPOL-Key frame (4/4 Pairwise)
Jul 27 08:02:24 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d IEEE 802.1X: authorizing port
Jul 27 08:02:24 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d RADIUS: starting accounting session 8C39DF124A02E729
Jul 27 08:02:24 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: pairwise key handshake completed (RSN)

Arp table:

# arp -a
? (192.168.50.20) at <incomplete> on br0

Restarting the hostapd seems to always help.
Hostapd logs are exactly the same as on normal connection.
"No problem" connection:

Jul 27 08:09:21 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d IEEE 802.11: associated
Jul 27 08:09:21 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: event 1 notification
Jul 27 08:09:21 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: start authentication
Jul 27 08:09:21 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d IEEE 802.1X: unauthorizing port
Jul 27 08:09:21 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: sending 1/4 msg of 4-Way Handshake
Jul 27 08:09:21 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: received EAPOL-Key frame (2/4 Pairwise)
Jul 27 08:09:21 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: sending 3/4 msg of 4-Way Handshake
Jul 27 08:09:21 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: received EAPOL-Key frame (4/4 Pairwise)
Jul 27 08:09:21 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d IEEE 802.1X: authorizing port
Jul 27 08:09:21 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d RADIUS: starting accounting session E33ADF35DE9F0978
Jul 27 08:09:21 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d WPA: pairwise key handshake completed (RSN)

Arp table:

# arp -a
? (192.168.50.20) at 00:16:a5:88:04:4d [ether] on br0

The only suspicious thing I see in logs (in general, during and not during the problem, as well as it might not appear even during the problem) is

Jul 27 07:46:38 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d MLME: MLME-DEAUTHENTICATE.indication(00:16:a5:88:04:4d, 2)
Jul 27 07:46:38 bpir101 hostapd: wlan0: STA 00:16:a5:88:04:4d MLME: MLME-DELETEKEYS.request(00:16:a5:88:04:4d)

What might be the problem? Fill free to ask me for any additional info, logs, configuration or testing.
Hostapd conf:

# cat /etc/hostapd/hostapd.conf
interface=wlan0
bridge=br0

driver=rtl871xdrv

# This advertises the country_code and the set of allowed channels and transmit power
# country_code=DE
# ieee80211d=1

# Maximum data rate 54Mbps in 802.11g and 300Mbps in 802.11n
# The RTL8192CU provides simple legacy and 20MHz/40MHz co-existence mechanisms to ensure 
# backward and network compatibility. Maximum PHY data rate up to 144.4Mbps using 20MHz 
# bandwidth, 300Mbps using 40MHz bandwidth # if you do not have a wireless N capable device = 0
ieee80211n=1

# 2,4GHz bandwidth
channel=4
hw_mode=g
wmm_enabled=1
# A message from 2012; (If Debian enabled MAC80211_DEBUG, then you can take a look at the map in /sys/kernel/debug/ieee80211/phyX/ht40allow_map.
# It tells you which HT40+/- mode is supported at which frequency/channel)

# However, don't get your hopes up, because "According to 802.11-2012, APs and routers must default to 20 MHz bandwidth mode in the 2.4 GHz band. 
# They may switch to 40 MHz bandwidth mode only after satisfying multiple criteria, including no "fat channel" intolerant bit set and no interfering APs.

# In addition, to meet spec, APs are not allowed to have a "40 MHz only" mode in the 2.4 GHz band.
#ht_capab=[SHORT-GI-20][SHORT-GI-40][HT40-][DSSS_CCK-40]
ht_capab=[SHORT-GI-20][SHORT-GI-40][HT40][DSSS_CCK-40]

# Identification and Login
ssid=ssid-radio-50
#1 - hide ssid
#0 - show ssid
ignore_broadcast_ssid=1
#ignore_broadcast_ssid=0
wpa_passphrase=ssid50ps
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
rsn_pairwise=CCMP
#wpa_pairwise=TKIP CCMP
auth_algs=1
wpa=2

macaddr_acl=0
beacon_int=100
max_num_sta=8

#noscan=1

# Temporary configuration file
ctrl_interface=/run/hostapd/

device_name=RTL8192CU
manufacturer=Realtek

# hostapd event logger configuration
#
# Two output method: syslog and stdout (only usable if not forking to
# background).
#
# Module bitfield (ORed bitfield of modules that will be logged; -1 = all
# modules):
# bit 0 (1) = IEEE 802.11
# bit 1 (2) = IEEE 802.1X
# bit 2 (4) = RADIUS
# bit 3 (8) = WPA
# bit 4 (16) = driver interface
# bit 5 (32) = IAPP
# bit 6 (64) = MLME
#
# Levels (minimum value for logged events):
#  0 = verbose debugging
#  1 = debugging
#  2 = informational messages
#  3 = notification
#  4 = warning
#
logger_syslog=-1
logger_syslog_level=0
logger_stdout=-1
logger_stdout_level=0

Took hostapd sources from here http://w1.fi/releases/hostapd-2.6.tar.gz
and build with your patch and .config file.
Hostapd started like

# ps ax | grep hostapd
12271 ?        Ss     0:00 /usr/sbin/hostapd -B -P /run/hostapd.pid /etc/hostapd/hostapd.conf

Kernel:

# uname -a
Linux bpir101 3.4.112-sun7i #2 SMP PREEMPT Sat May 28 20:25:03 CST 2016 armv7l GNU/Linux

I understand that this is mostly "build" issue tracker, but I could not found any general hostapd bug tracker, you might advise me where to rise this problem. Thanks in advance.

[pritambaral]

I understand that this is mostly "build" issue tracker, but I could not found any general hostapd bug tracker

Sorry, but that still doesn't not make this any sort of a hostapd bug tracker.

Even if you did manage to ask this on the hostapd mailing list or mail the author of hostapd, you still may not receive support because you are using a (shitty) fork of hostapd, and the problem likely exists with the shitty code of the fork than with hostapd proper.

You really should not be using Realtek's shitty code. Use the in-kernel driver from mainline, and use unpatched hostapd.

[kgara]

Just minor update - have exactly the same problem on armbian 5.31/ 4.9.7 kernel

$ uname -a
Linux lamobo 4.9.7-sunxi #1 SMP Thu Feb 2 01:52:06 CET 2017 armv7l GNU/Linux

with stock hostapd, driver=nl80211
Actually the average quality is even worse (comparing to 3.4 with patched hostapd) - average ping to wifi devices might be 1200ms, huge packet loss.
Guys from hostapd had not reply in mail list. At least now I have 100% legal permission to blame mainline hostapd.

[pritambaral]

If it repro'd on mainline, chances are high the hardware is shitty.