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

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Wed, Jan 16, 2019 at 01:08:21PM +0100, Arend Van Spriel wrote:
> 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?

With a split build tree, and brcmfmac as a module.  I've just moved
drivers/net/broadcom/brcm80211 out of the way and re-built with verbose
mode enabled.  The gcc lines show that they are indeed passed -DDEBUG.

If I look inside the sdio.o object, I do find the strings:

intrcount:    %u
lastintrs:    %u
pollcnt:      %u
regfails:     %u

which are from brcmf_debugfs_sdio_count_read(), and is only built when
DEBUG is defined - so the build looks correct.  I also find this in the
module I have on the target system, so it too was indeed built with
-DDEBUG as intended.

Nope, your debugfs support can't possibly work for anyone in 4.20.

sdio.c sets up the debugfs stuff in brcmf_sdio_debugfs_create() which
wants wiphy->debugfsdir.  This is called via brcmf_bus_preinit() from
brcmf_sdio_bus_preinit().  This happens before brcmf_cfg80211_attach().

This is the key point - brcmf_cfg80211_attach() calls wiphy_register(),
which is where the wiphy's debugfs directory is setup:

        /* add to debugfs */
        rdev->wiphy.debugfsdir =
                debugfs_create_dir(wiphy_name(&rdev->wiphy),
                                   ieee80211_debugfs_dir);

Consequently, at the time when brcmf_sdio_debugfs_create() is called,
the debugfs directory has not been setup, so the function merely
returns.

> 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
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up