[Solved] Independence of STA and AP interfaces handling

For Developers
1

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.

2

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.

3

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).
4

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.

2 Likes
5

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

6

Hi @VincentR and @jow,

although this is 5 years old - thanks a lot for the information!

I ran into that problem just now with 22.03.5 - STA not associating because of wrong config, and AP not coming up. Until now, finding your conversation, I was not aware why this needs to be that way (STA channel search would make AP channel hop...).

Still, for a Wifi-only device, this is an unfortunate situation - one config typo setting up the STA and the device is no longer accessible (except via serial console).

Yes, something like that would be great to recover wifi-only devices via AP. Did you find a way to do something along these lines, in the meantime?

7

Hi @luz ,
I remember implementing a monitoring script which would start when STA was trying to connect to a new SSID. It would check for a valid route every second for about 30s (found it more reliable and faster than calling the iw functions). If nothing came up, it would kick in and revert the STA to be disabled so the AP would come back to life (at the risk of having lost the connected device and requiring a manual reconnect at the OS level).

I used the return value of:
ip route | grep '^default' > /dev/null

Hope that helps!

8

Hi @VincentR,

Thanks for your reply!

I started experimenting with a monitoring script, too, currently using the return value of

ubus call network.device status '{"name":"wlan_cli
"}' | grep -q '"carrier": true'

(in my setup, the STA interface is called wlan_cli)

But checking for the presence of a default route is probably a more generic and also simpler solution.

Thinking about, it also has the advantage that it would not trigger when the device has a wired connection, only when there is no connection at all.

Thx again :grinning:

9

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.