[Solved] Independence of STA and AP interfaces handling

Hi all,
First, this is as seen on MT7620 and MT7603e even if I suspect it is in more places.

The issue is simply that when you have some APs and at a STA configured, if the STA fails to connect using the provided configuration (for example due to a bad key/password), then the APs never come up. To be clear, if you disable that STA, all APs come up fine and you can also bring them up manually at any time with ifconfig/ifup.

I've come across multiple solutions that workaround this limitation by "manually" handling the interfaces (like WifiMgr and TravelMate - thanks guys!). I've also implemented variations of these workarounds, but I've never been able to find out where the code that links these interfaces together is. So I'm left with the feeling that it is my lack of understanding which leads me to those "unsavoury" workarounds.

I don't know where to look if I wanted to change that behaviour either by a configuration change or a code patch...
I suspect it could be somewhere around hostapd, wpa_supplicant, the wifi shell script, the Wi-Fi drivers or maybe the kernel, but couldn't find it.

Any pointers are welcome.

It is in hostapd. The reason it does it is because the STA code will scan through RF channels until its AP is acquired. Thus any AP running on the same radio would be hopping around and not usable by clients.

Thanks @mk24!
That makes complete sense. And yet, who wouldn't want to be able to access an AP to connect to their router when STA fails connecting (particularly if that router doesn't have Ethernet ports).

Following your answer, I had a good look around the hostap/wpa_supplicant code (https://w1.fi/cgit/hostap/) without that much luck. It shows that there are communication channels (event driven callbacks and even some CLIs) that can be used and that typically drivers would callback with these specific events... but I can't find the logic within hostapd around enabling/disabling APs.

I also went back to the LEDE code and started looking for the calls to these tools and tracing my way back, I ended in package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh for hostapd and package/network/services/hostapd/files/hostapd.sh for wpa_supplicant. At least, I think I'm clear as to how hostapd and wpa_supplicant are configured and started.

I had a look at iwinfo since it interacts with hostapd and wpa_supplicant as well as the driver but I don't think the magic is in there (famous last words). I then had a look at iw which mentions wpa_supplicant and hostapd as handling frames that are not dealt with by the kernel.

So at this stage, I'm a little lost again and trying to figure out two things:

  • where is the logic to disable/enable the APs?
  • what triggers that logic? (association, disassociation type events that bubble up to hostapd?)

NOTES:

  • Thanks for the help, this is more of a knowledge building exercise than a request for help at this stage so I'd understand if this thread goes stale.
  • I'm also going to move it to the development section as the idea is to see if I can play with the logics around these triggers (initially for my own understanding).

The AP/Sta handling code is hidden in LEDE specific patches, see https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/hostapd/patches/370-ap_sta_support.patch - in particular see the hostapd_stop() and hostapd_reload() calls.

I think the best solution would be to add some kind of configurable timeout after which the association attempts are given up and hostapd is brought up anyway, maybe in conjunction with periodic scheduled (passive or active) scan cycles to retry the sta association.

1 Like

Thanks very much @jow,
that's what I was looking for. I'm going to have a look at this in more depth.