WIZARD SCAN FOR HALOW NETWORKS
In 2.6.6, when I clicked the scan button on the connect halow network page, the scan came back really quick with the ssid from the ap I’m using. In 2.9.3, it takes a really long time. It often doesn’t find it. Has something changed that affects this?
Guys, I have several open items in this thread I could use help on that are over a week, notably the dpp that’s not working right yet. Will you be able to break away and take note of those I have in the queue to be addressed? Would appreciate it.
Hi @don.baker
Apologies for the late reply.
If I recall correctly, option.write overrides how the option is written to config. option.forcewrite is a flag to enforce that option.write is always called, even if the value set is the default value for that configuration.
It will be by design for each of the items. Sometimes we have special handling which requires a value be inserted, even if it is the default.
Rangetest is an application to ease the running of iperfs in the field from a single device, to facilitate range tests. It will search for devices to communicate with, and allow you to configure a “test” from the access point which will remotely configure iperfs on the devices under test as required.
The management alias IP is an attempt to allow users to regain access to their devices if they have accidentally bridged a device and “lost” the IP address. This can happen when a device is configured in bridge mode, but is not connected to a network with a DHCP server to give it a new address.
I believe we might be removing this from a future revision as some systems don’t like /31 addresses!
This comes from the morse-mgmt-iface package and can be disabled if you don’t require it. See morse-feed/features/morse-mgmt-iface at 76f92454aa62f6ad0fa7bfa047dbe433a2a477d2 · MorseMicro/morse-feed · GitHub
Not to my knowledge. “Often doesn’t find it” is very concerning and not something we’ve seen locally.
Can you ssh into the device you are running the wizard on, and run logread -f. Then go through the steps of the wizard up to and including a failed scan?
Hi, Arien.
I got rid of the management alias stuff in menuconfig: Morse Micro/Features, deselect morse-mgmt-iface.
doing logread -f, then clicking the ‘scan’ button on the quick config page produced nothing in the log for that action. The combo in the client web page populated with the current ssid as well as the ap’s ssid, but there were no log entries
DPP issues…Lyall had provided something to try for dpp, but that didn’t help. This is the MOST important thing that isn’t functionally working well…dpp. In 2.6.6, dpp worked every time until the 7th try, then it would fail from then on. Between that issue and the assurances of the work put into dpp that 2.9.3 would help, we had to pursue going to 2.9.3, which has been no trivial task to bring in our custom changes to accommodate the architecture mods, particularly for new directories and changed file locations. But now…dpp often doesn’t work and you don’t know when it will or won’t. It is VERY important that we get this working. I’ll provide any diagnostics necessary to help and even Justin said he could ship you guys a board or 2 you can load our image on if that helps expedite the process. Justin said he knows from talking to your folks with other stuff that y’all are really busy, though we are at a point of ready to start shipping product and need dpp capability to work 100%. Anything you can do to get us moving in a solution for this?
Can you do a capture from the start of the wizard? Not just the scan button. I want to verify that the AP is happy with the configuration being given, and that the interface is coming up correctly.
In a very early unreleased version (pre-2.6.6) there were timing issues wrt the UI showing the capability to scan, before the interface had started - especially if the country code was changed.
You sent some AP logs above, but unfortunately all they show is that DPP is failing, and the AP logs appear to be missing the start. Can you elevate the log level by setting option log_level '0' in the wifi-device section of option type 'morse' in /etc/config/wireless and then run reload_config.
Please send an email to support@morsemicro.com if you haven’t already, but we will keep debugging of these issues to the forum.
Is there a git repository from where we can look at the changes made to the OpenWrt fork?
Hi, Arien. I finally got around to re-doing the log for you on the AP. I have notes in the top of the file, please note those when you look through the log. Basically, I ran 2 trials and each produced the identical behavior: dpp worked the first time, failed the 2nd time.
I don’t have the source on git anywhere currently.
2.9.3 AP log - dpp failed 2nd time.txt (217.7 KB)
I meant to do the station to see if you wanted to correlate the 2, but only have the end of the 2nd dpp attempt:
Thu Dec 18 14:45:25 2025 daemon.notice wpa_supplicant_s1g[14113]: wlan0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5745 type=19
Thu Dec 18 14:45:25 2025 daemon.notice wpa_supplicant_s1g[14113]: wlan0: DPP-PB-STATUS start push button PKEX responder on the discovered channel (5510 MHz)
Thu Dec 18 14:45:25 2025 daemon.notice wpa_supplicant_s1g[14113]: wlan0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=5510 type=19
Thu Dec 18 14:45:25 2025 daemon.notice wpa_supplicant_s1g[14113]: wlan0: DPP-RX src=1c:bc:ec:21:64:3f freq=5510 type=20
Thu Dec 18 14:45:25 2025 daemon.notice wpa_supplicant_s1g[14113]: wlan0: DPP-RX src=1c:bc:ec:21:64:3f freq=5510 type=18
Thu Dec 18 14:45:25 2025 daemon.notice wpa_supplicant_s1g[14113]: wlan0: DPP-TX dst=1c:bc:ec:21:64:3f freq=5510 type=8
Thu Dec 18 14:45:25 2025 daemon.notice wpa_supplicant_s1g[14113]: wlan0: DPP-TX-STATUS dst=1c:bc:ec:21:64:3f freq=5510 result=no-ACK
wpa_s1g_dpp_action.sh: state=failed
diag_override.sh: set_state dpp_failed
Hi Don,
Thank you for the logs.
As for the 2 minute lockout time you mention there is nothing that can be done about that as it is a security feature defined by the standard and is hardcoded throughout the hostap binary.
I cannot see anything obviously wrong with your logs and I have spent time attempting to recreate the issue to no avail but in order to properly diagnose the problem, can I ask that you repeat the testing again with the same high log level but also capture the STA side logs too and post them with no abbreviation? Given that DPP is a conversation I do need to properly synchronise it on both sides to understand who is the problem child.
Just based on a sneaking suspicion, if you are able to could you potentially attempt this with power save disabled? If it is necessary for your application then don’t worry. You can confirm it has been turned off by enable_ps: 0 in the driver modparams listed in the logs when it loads.
Thanks!
Hi, Lyall. Good catch on the power save. In the log it was enable_ps=2, but as part of my project, I have this changed to set it to 0 in ./build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/morse_driver-1.16.4/Makefile:
#Default enable_ps to POWERSAVE_MODE_FULLY_ENABLED
#original; chg to take away power save CONFIG_MORSE_POWERSAVE_MODE ?= 2
CONFIG_MORSE_POWERSAVE_MODE ?= 0
ccflags-y += “-DCONFIG_MORSE_POWERSAVE_MODE=$(CONFIG_MORSE_POWERSAVE_MODE)”
The makefile didn’t get touched when it was copied over (part of my build process, I have a separate directory set with all files that changed from sdk baseline, that way for new sdk I can use that as the basis for all changes); thus, ps was still 2. It’s 0 now.
When I first did dpp, it worked. Then it worked again, so I thought we were home free. Then it failed on try #3. Then I realized I didn’t turn on extra logging so had to do it again. I rebooted and it failed the first time. I then rebooted again and started logs from the top on each sta and ap. Then it did the 1st 2 dpp attempts successfully, then failed the 3rd. So, repeatable result. The logs are here.
sta - dpp worked twice then failed.txt (117.5 KB)
ap - dpp worked twice then failed.txt (71.5 KB)
Does this tell you anything? If not, and we exhaust things you’d suggest to try, for sake of expediency how can we arrange to have our hw guy who designed the boards send y’all 2 boards to work with in-hand? That would give you direct visbility into what I’m working on.
@don.baker not sure if you missed it earlier, but please send an email to support@morsemicro.com to organise where to send hardware.
Thanks, that process is now underway.
A couple of things:
I’m thinking the dpp issue has something to do with the AP. Why? When I use the same hilink station with a silex AP, dpp has worked every time. Would that tid-bit give you any pause to think where the issue might be using our hilink AP?
I’ll have to look at this again, but yesterday when I was trying to setup a fresh station and fresh ap, I purposely set the station to have a different halow ssid in the wizard than the ap.I went to the quick config screen, clicked the search button next to halow ssid, it found the ap’s halow ssid, I set encryption and key properly, clicked ‘save and apply’, it saved it, but watching my console debug windows there was no activity or attempt to connect halow. I tried clicking save and apply again and of course it said no changes were made. I couldn’t connect halow that way.
Remind me, were there action scripts running on the AP side? I wonder if something is impacting the timing. We will try to debug when the boards arrive.
Perhaps, as an experiment, what happens when you remove the action scripts and try DPP again?
If the settings were definitely correct (confirm by inspecting /etc/config/wireless) then that is definitely unexpected. If you are able to reliably reproduce this, it would be useful to run wifi down then wifi up on the station to manually kick it, and see if it continues to fail.
Action scripts? Could you help me for what your referring to, as in…?
Regarding timing, when I was doing 2.6.6, silex had suggested some timing mods that actually seemed to help 2.6.6. I put these in 2.9.3, also, but maybe they don’t help this? Agree due to the intermittent nature of whether dpp works or not on our all hilink (sta and ap) system makes timing a possible theory.
In ./build_dir/target-mipsel_24kc_musl/hostapd_s1g-1.16.4/src/ap/dpp_hostapd.c, hostapd_dpp_pkex_init(), this is inserted:
hapd->dpp_pkex = pkex;
msg = hapd->dpp_pkex->exchange_req;
//wait_time = 2000; /* TODO: hapd->max_remain_on_chan; */
//per silex
wait_time = 3000;
//end per silex
pkex->freq = 2437;
Same file, ostapd_dpp_pkex_retry_timeout():
if (!pkex || !pkex->exchange_req)
return;
//silex said try 10
//if ((!pkex->exchange_done && pkex->exch_req_tries >= 5) ||
// (pkex->exchange_done && pkex->commit_reveal_tries >= 5)) {
if ((!pkex->exchange_done && pkex->exch_req_tries >= 10) ||
(pkex->exchange_done && pkex->commit_reveal_tries >= 10)) {
if (hostapd_dpp_pkex_next_channel(hapd, pkex) < 0) {
And at the end of hostapd_dpp_pb_pkex_init() :
send_frame:
wpa_msg(hapd->msg_ctx, MSG_INFO, DPP_EVENT_TX “dst=” MACSTR
" freq=%u type=%d", MAC2STR(src), freq,
DPP_PA_PKEX_EXCHANGE_REQ);
hostapd_drv_send_action(hapd, pkex->freq, 0, src,
wpabuf_head(msg), wpabuf_len(msg));
//pkex->exch_req_wait_time = 2000;
//per silex
pkex->exch_req_wait_time = 3000;
//end per silex
pkex->exch_req_tries = 1;
Also, in ./build_dir/target-mipsel_24kc_musl/wpa_supplicant_s1g-1.16.4/wpa_supplicant/dpp_supplicant.c wpas_dpp_presence_ann_channels():
for (c = 0; c < mode->num_channels; c++) {
struct hostapd_channel_data *chan = &mode->channels[c];
if (chan->flag & (HOSTAPD_CHAN_DISABLED |
HOSTAPD_CHAN_RADAR))
continue;
#if defined(CONFIG_IEEE80211AH)
//-------------------------------------------------
//mod per silex; they said without it, dpp will fail
unsigned int s1g_chan = 0;
static const int s1g_chirp_channels = {
// 2MHz channels
5190, 5230, 5270, 5310, 5510, 5550,
5590, 5630, 5755, 5795, 5835,
// 1MHz channels
5680, 5180, 5200, 5220, 5240, 5260,
5280, 5300, 5320, 5500, 5520, 5540,
5560, 5580, 5600, 5620, 5640, 5765,
5785, 5805, 5825, 5845, 5865
};
for (s1g_chan = 0; s1g_chan < ARRAY_SIZE(s1g_chirp_channels); s1g_chan++) {
if (chan->freq == s1g_chirp_channels[s1g_chan])
int_array_add_unique(&freqs, chan->freq);
}
//----------- end mod -----------------
if (chan->freq == preferred_s1g_ht_freq)
add_s1g_chan = 1;
I just did an experiment, interesting behavior…2 cases:
2.6.6 in station, 2.9.3 in AP. DPP worked first time, failed 2nd time, same as when 2.9.3 is in station.
2.9.3 in station, 2.6.6 in AP. DPP worked 8 times then failed twice.
So, case 2 above was better, but still acts like a full 2.6.6 system, where dpp consistently worked 6 times then failed from then on.
Case 1 is like a full 2.9.3 system. Almost every time, dpp works once then fails.
However, like I said before, I have yet to have any dpp failure using a silex board as ap and either 2.6.6 or 2.9.3 on the station. That’s why I lean to the 2.9.3 ap being the issue, if that makes sense.
Then, a question…as previously explained, the 2 min wait period after dpp fail in 2.9.3 is necessary. But, why wasn’t there a 2 min wait period in 2.6.6 after dpp fail? It just finished with fail and you could move on right away.
also, while it doesn’t happen every time, every so often in my station Quick Configuration page, when I set the halow ssid to something like ‘test’, then apply, then click the search button and it fills in halow ap’s, every so often the encryption is set to OWE and the key is blank. Any reason you can think of for why it does that? I never saw it do that on 2.6.6.
I found a case that it just happened. Station was connected to an ap. I turned off that ap and started another that had a different halow ssid. I clicked the search button on the station halow ssid web page, it showed the old one with no bars, the one for the other ap with rssi level. When I picked it, the encryption was OWE and the key was blank. Is that by design that it changes those? I wanted it to stay the same for both items.
It’s definitely worth trying DPP without these mods, just to rule them out at least.
The scripts you were passing into supplicant and hostap with the -a parameter (which you were doing some time ago, i assume they’re still used?). As above just want to rule things out and take the setup back to the bar minimum to isolate the problem. There may or may not be something required for DPP in these actions scripts so only attempt it if you can.
In our 2.6.6 release you should consider the lack of the 2 minute wait a bug. There will be scenarios where the session overlaps will cause an inability to connect at all, and possibly even associated security risks.
Sounds like it might be attempting to detect the encryption type from the ssid. @james.haggerty is probably better placed to give an answer this.
On the first item: I removed the things silex suggested in the dpp_hostapd.c file…dpp failed the first time. Restored to adjusted settings and dpp worked 1st time.
On the next item, if I’m understanding right, search doesn’t come up with any -a param on any hostapd from what I saw. I have this in /etc/rc.local:
#kick off the hostap-leds service /etc/init.d/hostap-leds here so
#the command “hostapd_cli_s1g -i wlan0 -a /lib/functions/clientconnected.sh”
#doesn’t have to be used to force the client connect status change
service hostap-leds enable
service hostap-leds start
The failure mode you’re seeing from the last logs is:
Tue Jan 20 14:22:47 2026 daemon.notice wpa_supplicant_s1g[9586]: wlan0: DPP-FAIL No matching peer bootstrapping key found for PKEX - ignore message
on the supplicant side.
This would usually happen if the patch that @packet_sniffer provided has not been correctly applied.
Can you confirm that this patch is applied, and get the logs from a failed interaction again?
It would be extra helpful if you could run:
hostapd_cli_s1g log_level debug
wpa_cli_s1g log_level debug
on either side after bringing up the interface.
Thanks.
Hi, James. There are 3 files that patch affects. The first 2 (src/common/dpp.h and src/common/dpp_pkex.c) were ok, the other one (wpa_supplicant/dpp_supplicant.c) didn’t have the patch. I changed the source to reflect the patch for dpp_supplicant.c in both dirs:
./build_dir/target-mipsel_24kc_musl/hostapd_s1g-1.16.4/wpa_supplicant/dpp_supplicant.c./build_dir/target-mipsel_24kc_musl/wpa_supplicant_s1g-1.16.4/wpa_supplicant/dpp_supplicant.c
but I got dpp failure on the first attempt.
For those debug items, are those for processes running or when is that done? On the ap, doing “ps -ef|grep cli_s1g” gives “root 7114 1 0 16:05 ? 00:00:00 /usr/sbin/hostapd_cli_s1g -i wlan0 -a /lib/functions/clientconnected.sh” but there’s no process with cli_s1g on the station.
also…halow is only connecting by clicking the search button on the Quick Config page. After halow connected, I did dpp. After it failed dpp, it connected halow again anyway since that’s what it was, already, I guess. So, now halow is reconnected but its background task to finish dpp is taking its 2 min to finish. In the meantime, although halow is connected, the led is blinking as it wraps up the dpp fail processing. So here’s the question: led is supposed to blink when it’s doing dpp, then it keeps blinking during the 2 min, but isn’t there anything in the system that will kill the dpp stuff after halow reconnects in this case? Maybe this will be a non-issue when dpp itself gets fixed anyway, but it’s still weird.
Those are commands to run to force debug logging on for the interaction while the processes are running.
If you try to DPP PB when you’re already connected to the same AP it will always fail. As far as I know, however, there’s no reason to do this. The LED blinks while the lockout is present, letting the user know that they can’t initiate another DPP PB interaction in that time.
Please make sure that:
Then initiate DPP PB on the AP first then on the STA, and attach the logs of the interaction.