We have a project we’ve been working on and was able to get Morse support from Arien and James during late 2024, so they at least knew what we were working on, a board with hilink 7688 and silex sx-sdmah. We’re using the morse openwrt sdk 2.6.6. I was testing with 2 of our boards this week. One is setup as ap, ethernet/bridged, the other as client, bridged. I found an issue that happens very consistently and the only recourse for now is to power cycle the ap. That’s unacceptable for deployed use. When connected to halow the first time, I disconnect by changing the ap halow ssid. I reconnect by pressing our dpp button for the board which obviously launches the dpp process. Then, press the button on the station. After DPP finishes, they connect halow. I do the same cycle to disconnect/reconnect. Each time, there is an event that notifies us ./etc/init.d/hostap-leds. This file is enabled and started in /etc/rc.local to replace the command “hostapd_cli_s1g -i wlan0 -a /lib/functions/clientconnected.sh”. clientconnected.sh processes events like AP-STA-CONNECTED and AP-STA-DISCONNECTED, vital to things we need to be notified when those occur.
Here’s the problem: after the 6th time of doing that cycle, we stop getting the events for AP-STA-CONNECTED. One time I was still getting AP-STA-DISCONNECTED events but once, even that wouldn’t come through when halow disconnected.
I was wondering if anyone could assist with this? Is it a problem with something in DPP? Is it an issue with some driver or bcf file? Is the source of the issue something else? I wasn’t able to determine where those events are generated from to trigger the processing we do for them.
Using sdk 2.6.6. Our own boards using hilink 7688 and silex sx-sdmah, setup as station in bridge and ap in ethernet/bridge. When halow connects or disconnects, the station gets a hotplug notification that causes script files in /etc/hotplug.d/iface to be launched. We need this for post-connect/disconnect processing. However, if the station and ap have the same halow ssid, the station is up and running, the ap was powered down then the ap is turned on, when halow connects, the station will not get a hotplug event. Thus, we can’t do the vital post-connect processing that is needed. However, if I change the halow ssid on the ap to cause halow to disconnect, then press the dpp button on each board to start dpp, dpp works, halow reconnects and in this case the station does get the hotplug event and runs the scripts in /etc/hotplug.d/iface. Likewise, when the ap is powered down and halow is detected to be disconnected on the station, there is no hotplug event on the station to say the interface went down (ifdown on br-ahwlan). Does anyone know why the station doesn’t get a hotplug notification to run those scripts if the ap is turned on after the station is already up?
Is all of this because it’s a bridge-bridge setup? If I setup the station to ‘none’ or ‘extender’ and the ap to ‘none’, the hotplug notifications usually come in and I can process on those as desired.
I’ve collected both your messages into this one thread as it’s possible they may be related issues.
I wasn’t able to determine where those events are generated from to trigger the processing we do for them.
The events are generated from hostap/supplicant.
Is it a problem with something in DPP? Is it an issue with some driver or bcf file?
We have made some fairly significant improvements to how DPP is handled in hostap since 2.6.6. If you have the capacity to update, we recently release 2.9.3!
I disconnect by changing the ap halow ssid
I wonder if hostap is missing the disassociation frame from the station in the cases when the AP-STA-DISCONNECTED events don’t come through. After disconnecting the station, what is the output of hostap_cli_s1g -i wlan0 list_sta?
after the 6th time of doing that cycle, we stop getting the events for AP-STA-CONNECTED
Is there a delay element to this? For example, if you wait ~5 minutes between cycles is it more reliable, or will it consistently fail after the 6th attempt?
Is all of this because it’s a bridge-bridge setup?
It’s likely the bridge interface itself as linux sees it isn’t going down. When the the AP is powered down, run an ifconfig on the station, br-ahwlan will likely stay up particularly if there is ethernet link.
Can you attach the hotplug event to the specific interface included in the bridge instead, eg wlan0?
