Re: [REGRESSION] hostapd 2.4..2.7 broken with 4.18+

[Arend Van Spriel <arend.vanspriel@broadcom.com>]

On 1/16/2019 1:12 AM, Russell King - ARM Linux admin wrote:
> On Mon, Jan 14, 2019 at 12:49:09PM +0100, Arend Van Spriel wrote:
>> Could you try the compile and load test I suggested earlier. I will try to
>> replicate things over here as well.
> 
> I'm not sure that helps:
> 
> [588980.874745] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 286 expected 286
> [588980.875776] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 281 expected 281
> [588980.876925] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 2064 expected 2064
> [589095.542690] brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets
> [589098.262719] brcmfmac: send_key_to_dongle: wsec_key error (-110)
> [589100.822465] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON failed -110
> [589101.814313] brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets
> [589104.410194] brcmfmac: send_key_to_dongle: wsec_key error (-110)
> [589106.970045] brcmfmac: brcmf_cfg80211_change_station: Setting SCB (de-)authorize failed, -110
> [589109.530191] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON failed -110
> [589110.322685] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 28 expected 28
> [601235.163954] br0: received packet on wlan0 with own address as source address (addr:6c:ad:f8:05:0d:81, vlan:0)
> [601245.240024] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 28 expected 28
> [601264.207886] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 28 expected 28
> ...
> [605377.238304] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 28 expected 28
> [605395.118751] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 28 expected 28
> [605412.976951] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 28 expected 28

So actually it shows me that we are not getting responses. That and the 
pend8021x is starting to look pretty fishy, but lacking console messages 
may be build issue that I explain further down.

> Looking at the time the messages (at 589095.542690) are produced, what
> seems to cause this is when I head out with my LineageOS (TI WiLink
> based) phone to the car and drive off.  I've suspected that's the case
> with all the previous iterations of this problem too.
> 
> At this point, the LineageOS phone is completely unable to reassociate
> with the AP, but it can see the AP with varying amounts of signal - it
> shows medium signal, which drops to nothing when it tries to associate.
> As soon as it stops, the indicated signal seems to come back... not
> sure if that's a LineageOS thing or something that is really happening
> on the Broadcom side.
> 
> It looks to me like the older firmware is not happy about a station
> disappearing off into the distance... surely I can't be the only one
> who takes an associated station out of range of a BRCM4330 in hostap
> mode?

Thanks. Always good to have a scenario to trigger it. I tried setting it 
up over here. Everything looks fine but my stations don't see any 
beacons coming from it :-(

> I don't seem to have any messages from the firmware, and I can't find
> anything useful under /sys/kernel/debug for the driver - the only
> thing I have is:
> 
> # tree /sys/kernel/debug/ieee80211/phy5
> /sys/kernel/debug/ieee80211/phy5
> ├── features
> ├── fragmentation_threshold
> ├── fwcap
> ├── fws_stats
> ├── ht40allow_map
> ├── long_retry_limit
> ├── revinfo
> ├── rts_threshold
> └── short_retry_limit

That is weird. For SDIO it should also have three additional files:

forensics
counters
console_interval

The fact that these are absent suggests that sdio.c was not build with 
DEBUG define. How do you build the brcmfmac driver?

> 0 directories, 9 files
> 
> Also no devcoredumps appear to have been produced, although the
> facility is enabled.
> 
> I'm going back to the 2013 firmware now, which seems to behave itself.

I was also thinking about what has changed since 4.18. One commit that 
comes to mind is the rewrite of scatter-gather handling in bcmsdh.c, ie.
commit 4a5a553ddef7 ("brcmfmac: Use standard SKB list accessors in 
brcmf_sdiod_sglist_rw."). Maybe you revert that and try again.

Regards,
Arend