Sdk 2.9.3 changes from 2.6.6

Okay thanks Don, that’s much clearer. This will definitely be the morse-firmware-sign package triggering the warning. A simple solution would be to remove it from boards/common/packages_diffconfig and reinitialise your build.

I can share some information regarding how we sign images if you would like to use the same mechanism for your own products, but we are changing how we do that again in an upcoming 2.11 release. Replicating how we sign images will require you to insert your own public keys it /etc/opkg/keys, and securely store a private key somewhere.

Interesting, it’s possible these are set by soc specific base files (eg uci-defaults). Is there anything different between the two images in /rom/etc/uci-defaults or /etc/board.d ?
The other alternative is that a board name has been added to the compatible property of the device tree root node for the boards. In target/linux/ramips/dts compare the two top level .dts files for the two board targets your are examining.

I deselected morse-firmware-sign in Morse→features in menuconfig. I loaded that fw, then loaded it again. The force upgrade is still there. Why? Is there something residual in the build even when you deselect that option?

HOSTNAME as OpenWrt issue: I did an experiment. I started from scratch. I then did board setup built from board halowlink1, went into menuconfig and changed to hlk7688, also changed default ip addr to 192.168.3.1. I then used the ./files/etc/board.d/02_network with the only change being to make the hilink have a different lan port config so I could get to our board through ethernet. Guess what? After loading, the hostname came as expected. In the system card of the home page, Hostname is “hlk-7688a-481e”, not “OpenWrt”.

So… what is it about that build vs. my build?

Below is the code from ./package/base-files/files/bin/config_generate which I suspect is what this is about.

I use my board in initial setup to build the project just like above for halowlink1. But in the above paragraph, it seems it goes through the json ‘if’ block in the code below which sets the hostname as I’d expect but my board build doesn’t go through that ‘if’, thus, leaves hostname as “OpenWrt”. Am I looking at the right spot for this? Is there something else I’m not aware of?

generate_static_system() {

uci -q batch <<-EOF
	delete system.@system[0]
	add system system
	set system.@system[-1].hostname='OpenWrt'
	set system.@system[-1].timezone='UTC'
	set system.@system[-1].ttylogin='0'
	set system.@system[-1].log_size='64'
	set system.@system[-1].urandom_seed='0'

	delete system.ntp
	set system.ntp='timeserver'
	set system.ntp.enabled='1'
	set system.ntp.enable_server='0'
	add_list system.ntp.server='0.openwrt.pool.ntp.org'
	add_list system.ntp.server='1.openwrt.pool.ntp.org'
	add_list system.ntp.server='2.openwrt.pool.ntp.org'
	add_list system.ntp.server='3.openwrt.pool.ntp.org'
EOF

if json_is_a system object; then
	json_select system
		local hostname
		if json_get_var hostname hostname; then
			uci -q set "system.@system[-1].hostname=$hostname"
		fi

UPDATE: I just built another where I have my board directory. It did not build with the common folder b/c it didn’t use any luci themes. The halowlink1 uses morseargon. Then when I got the image loaded, the hostname was “OpenWrt”. I had the following in the boards/hlk-7688a/target_diffconfig file, which is slightly different than the halowlink1 file. What is the build doing different for halowlink1 that it puts the theme in .config and allows the hostname to be other than “OpenWrt”?

CONFIG_TARGET_ramips=y
CONFIG_TARGET_ramips_mt76x8=y
CONFIG_TARGET_ramips_mt76x8_DEVICE_hilink_hlk-7688a=y
CONFIG_TARGET_ROOTFS_INITRAMFS=n
CONFIG_VERSION_DIST=“ep-halow”
CONFIG_VERSION_CODE=“Morse-2.9.3-baseline”
CONFIG_VERSION_MANUFACTURER=“NexcommAP”
CONFIG_VERSION_MANUFACTURER_URL=“ Nexcomm Systems - Nexcomm Systems
CONFIG_VERSION_PRODUCT=“ep-halow”
CONFIG_TARGET_PREINIT_IP=“192.168.3.1”
CONFIG_TARGET_PREINIT_BROADCAST=“192.168.3.255”
CONFIG_TARGET_DEFAULT_LAN_IP_FROM_PREINIT=y
CONFIG_PACKAGE_morsectrl=y
CONFIG_PACKAGE_luci-app-ekhwizards=y
CONFIG_PACKAGE_morse-button=y
CONFIG_PACKAGE_persistent-vars-storage-ubootenv=y
CONFIG_PACKAGE_virtual-wire=y
CONFIG_PACKAGE_morse-led-rgb=y
CONFIG_MORSE_SDIO_ALIGNMENT=8
CONFIG_PACKAGE_morse-mgmt-iface=y
CONFIG_PACKAGE_wizard-config=y

Since that didn’t work, I copied the target_diffconfig from the halowlink1 dir into the hlk-7688a dir. The only difference was I replaced the 1st 4 lines with the 1st 4 lines above. After I did setup_morse, the following was in the .config:

CONFIG_PACKAGE_luci-theme-morseargon=y

So, now I’ll wait a while for make -j8 to build, and I’m going to make a guess: hostname will not be OpenWrt. Then I want to know…what is different, meaning what am I missing in the above original hlk-7688a target_diffconfig that it makes the hostname OpenWrt, which CONFIG_ setting is it?

I did discover CONFIG_PACKAGE_morse-fw-6108=y is necessary to have setup_morse select morseargon as the luci theme. Without that, no theme gets picked and morseargon isn’t even an option.

I’m going nuts trying to figure out what parameter(s) are necessary for the hostname to be something like “hlk-7688a-481c” instead of OpenWrt. I have been able to make it be not OpenWrt when building baseline using my hlk-7688a board dir which largely uses halowlink1 for most of target_diffconfig params. But when I try to make my other project have the same settings, that one always defaults hostname to OpenWrt. I have yet to find out what works.

Certificate checking happens if you include ucert on the image (see /lib/upgrade/fwtool.sh). I suspect you’ve included it on the image for other reasons. Check .config or menuconfig.

OTOH the default fwtool.sh should not check if the signature doesn’t exist, so it you make sure you the image isn’t signed at all you’ll probably avoid this.

DPP ISSUE: dpp is intermittent, sometimes it works, sometimes it doesn’t. I just tried a run of dpp button, change ap’s halow ssid, dpp button, repeatedly for 8 times. dpp failed on times 2, 6, 8. The 2.6.6 sdk would give me consistent dpp halow connection after change halow ssid…until the 7th time. From that point on it would fail. But it was very consistent. 6 times good, beyond that it failed.

I am using the bcf file I got from silex they made for morse driver 1.16.4 used in the sdk 2.9.3. I don’t know what is involved w/ the bcf and how it’s used, but is there any chance there could be issues with the bcf relative to the intermittency of dpp where you don’t know if dpp will work or not? At least on sdk 2.6.6, there was a much higher level of confidence dpp by the push button would work.

Plus, is there any way to get rid of that insidious 2 min wait after dpp push button fails? I get the msg from diag_override.sh that the state is dpp_failed, so why does the user have to wait another 2 mins for it to set the state to done? If it fails, to me it’s done and I want to move on and try again.

SETTING UP INITIAL BOARD DIR:

when you want to use your own board def as the readme notes say in boards dir, what determines if the items in the common and common_extras get used? I did find that you need CONFIG_PACKAGE_morse-fw-6108=y (or CONFIG_PACKAGE_morse-fw-6108-tlm=y, I don’t know what the tlm does for you) in your board’s target_diffconfig to at least get the common to use CONFIG_PACKAGE_luci-theme-morseargon=y from common/packages_diffconfig, but is there any way to override that item in this process, to use the theme-morse and make morseargon not be selected or is this simply a way to get it initialized to start with and you have to go into menuconfig to make tweaks before you do the make?

HOSTNAME AS OPENWRT ISSUE:

UPDATE 12/2: somehow I was able to get a baseline build using my hlk-7688a board definition to give the right hostname I expected, not OpenWrt, when I first loaded the image. I then made that my main project to include every file necessary to make this an image of our product. There are still a few other issues in the cutover to 2.9.3, but my first attempt to dpp failed, so that’s still an issue. However, I REALLY want to know what it is that allows the hostname to be what I want vs “OpenWrt”. I want to be able to explain it because I don’t want to have it be an unknown. “How did you get it to be what you want?” “I don’t know, it just did” is not an answer. I suspect it would be some parameter that’s set in .config, but I can’t figure out which one. There’s a lot of params that are different. If I sent you the 2 .config files of the one the sets hostname, when I first load the image, to “OpenWrt” vs the one I want, would you be able to know? How would I send it instead of this forum entry b/c the upload button just inserts a file as text here and those are big files.

DPP ISSUE: I tried to do dpp with the station using 2.9.3 and the ap using 2.6.6. Although both the station and ap in their logread showed “DPP-PB-RESULT success”, halow didn’t connect. I tried that b/c I’m not having good results with dpp with ap at 2.9.3, sometimes dpp fails, sometimes it’s successful, so I thought I’d see. So, even though that initial test worked, how can I find out why didn’t the boards connect halow? Is a 2.9.3 board image not compatible with a 2.6.6 board image?

My console debug messages for that process on the station:

DPP Button pushed, please wait…
wpa_s1g_dpp_action.sh: state:started
diag_override.sh: set_state dpp_started
wpa_s1g_dpp_action.sh: state:config
wpa_s1g_dpp_action.sh: state:finished
diag_override.sh: set_state done

With 2.9.3 loaded in the ap, here’s the series when it fails:

DPP Button pushed, please wait…
wpa_s1g_dpp_action.sh: state:started
diag_override.sh: set_state dpp_started
wpa_s1g_dpp_action.sh: state:failed
diag_override.sh: set_state dpp_failed
diag_override.sh: set_state done

However, halow will connect when I go to the station web page quick config, scan for the halow ssid and save/apply.

Hi Don!

I’ve crafted and attached a small patch that may address the DPP failures which you are seeing on 2.9.3. It targets an intermittent issue seen in the PKEX phase of the DPP flow where slower devices can end up in an incorrect state.

The patch allows the DPP enrollee (your STA) to ignore incorrectly repeated PKEX exchange requests from the DPP configurator (your AP).

This patch will only apply to your 2.9.3 builds and should help with your 2.9.3 ←→ 2.9.3 case specifically.

To implement this fix, drop it into the existing patches directory in the root of your OpenWrt build, and re-run the appropriate scripts/morse_setup.sh to apply them before rebuilding.

Let me know if this helps with the problem.

005-add-PKEX-overlap-patches-to-s1g-hostap-packages.patch (10.1 KB)

Hi, Lyall. Thanks. I did as you said, added to patches dir, did the morse_setup.sh, then built (I did not do any dirclean or distclean, just went right into make -j8). Upon loading the image into sta and ap, I purposely made the halow ssid’s be different so I would be forced to do dpp to get halow connect. I did and it quickly worked; halow connected. I was hopeful so I wanted to see 10 cycles where I’d change halow ssid on ap to disconnect halow, then do dpp button again. The first time I tried that….failure. In the logread on ap, during dpp, once it started outputting this line with success instead of failure (daemon.notice hostapd_s1g: wlan0: DPP-TX-STATUS dst=1c:bc:ec:21:64:45 result=SUCCESS), which there were many of those in the log, it stayed SUCCESS each time. Then halow connected. However, when dpp failed, the ap started having those SUCCESS lines then they turned to FAILURE from that point on and never went back to SUCCESS. Then, of course, dpp reported as failed on sta and ap.

  1. an item of note, we have a silex board that is also an ap we can use. With it and using the hilink 2.9.3 as station prior to the patch you sent, I was able to do 10 cycles of dpp button, change halow ssid to force disconnect, and repeat to connect/disconnect halow and it works every time. Similarly, I can use a station with 2.6.6 and dpp is successful every time.

  2. are there any logs that would be helpful for you to see?

  3. is there anything that can be done about that 2 min period between when dpp fails (diag_override.sh: set_state dpp_failed) and says it’s done (diag_override.sh: set_state done)? Like my previous note, that’s really annoying to wait 2 mins and our tech doing testing will not be happy to have to wait. Like I said, when it reports failed, to me (and eventually him when he gets to using this) it’s done and I don’t want to wait 2 mins to try again.

Hi Don,

Thanks for the quick feedback.

  1. Your test strategy is correct, as long as you change the SSID between attempts the DPP should be able to succeed. As for the different hardware showing better results, I should mention that slower systems are more prone to failures. The bug which I sent you the patch for was only ever visible on systems which were experiencing CPU bottlenecks. Are the CPUs/devices involved in your failures generally less performant than the ones in your success cases? Failures on slower systems are generally due to the tight timing windows defined in the Wi-Fi EasyConnect standard.

  2. Logs would be great. If you could attach the logread output as a file during a failed test from both sides of the transaction (AP & STA) I will be able to identify at what point in the exchange the devices stop talking to each other and hopefully why. Multiple failures would be even better so I could check whether it was always failing in the same location.

The daemon.notice hostapd_s1g: wlan0: DPP-TX-STATUS dst=1c:bc:ec:21:64:45 result=FAILURE you mentioned are of interest but the more important messages are the ones that include the type=* i.e. DPP-RX src=18:9b:a5:18:45:1e freq=5560 type=2 this shows what stage of the dance both devices reach and where they stop. The meaning of each “type” number is found here in our source and the expected order and behaviour of these message types are defined in the Wi-Fi EasyConnect standard.

Above all the main message to look for determining whether the core DPP transaction succeeded is always DPP-PB-RESULT <success|failed>. Unlikely in your case but sometimes people report bugs where the core DPP was succeeding but the post-DPP handling (i.e. translating the received credentials into an actual connection) failed.

  1. Yes, the 2 minutes is always annoying, but is a security feature. The “recommended” workaround is to power cycle both devices to forcefully reset said lockout period, but this may be even more annoying depending on boot times. I have not done it but I would expect that modifying the code to remove the lockout would be an involved exercise.

Just to add on to what @packet_sniffer said, there are a couple of other things to note here:

  • hostapd detects ‘session-overlap’ if it’s seen a previous DPP bootstrapping hash within 2 minutes of a new one that comes in. Due to STAs generating a new bootstrapping key for each interaction, this could be the same station as before!
  • this means we want to signal to the user to not try again for a long time, as it’s unlikely to succeed.
  • in testing, if you’re using 2.9, you can prevent our ‘lock’ by removing ‘/tmp/dpp_state_info.json’, but you probably also want to clear hostapd’s memory of previous interactions to actually avoid the session overlap. You can do this by restarting hostapd_s1g with wifi up radio0 (or whatever the appropriate radio is).

I probably mentioned this before, but DPP push button has a number of drawbacks (security and usability), so if there’s any other provisioning mechanism on the table…

SETTING UP INITIAL BOARD DIR:

when you want to use your own board def as the readme notes say in boards dir, what determines if the items in the common and common_extras get used? I did find that you need CONFIG_PACKAGE_morse-fw-6108=y (or CONFIG_PACKAGE_morse-fw-6108-tlm=y, I don’t know what the tlm does for you) in your board’s target_diffconfig to at least get the common to use CONFIG_PACKAGE_luci-theme-morseargon=y from common/packages_diffconfig, but is there any way to override that item in this process, to use the theme-morse and make morseargon not be selected or is this simply a way to get it initialized to start with and you have to go into menuconfig to make tweaks before you do the make?

Everything in common is used (always), and common_extras is used only if you have a symlink OR you use the -x argument when running setup.

As you determined, you always want a firmware, but the best way to do that would be to put that in your board definition and not in target_diffconfig.

Re luci-theme-morse, we have not touched this in some time, and I would not recommend using it without validating every page. But if you don’t want to use luci-theme-morseargon and want to avoid modify common, you can explicitly set it to ‘=n’ in target_diffconfig. I would just modify common in your situation.

Thanks for the explanations, Lyall. Logs attached.

I assume the things you are discussing pertain largely to the AP? The reason I ask is from my previous note, DPP works every time with a silex board we use as an AP, but usually doesn’t work on our board with hilink as AP, while using the same hilink STA. That’s why I am pointed to it being an AP issue on dpp. From what Arien and James described weeks ago with the work that was done to improve dpp, this is the reason we’re upgrading to 2.9.3 now. With 2.6.6, dpp largely worked, but after 6 rounds of changing the halow ssid and doing dpp again, from the 7th one-on, dpp failed. That was consistent.

I rebooted them at the same time, so the times in log may correlate. There are 2 dpp attempts, one right after the other, each attempt behaved different in the logs.

AP kernel log.txt (31.2 KB)

AP system log.txt (67.6 KB)

STA kernel log.txt (30.6 KB)

STA system log.txt (67.5 KB)

The first dpp attempt, the ap log started out showing SUCCESS, then FAILURE. When the sta stopped logging anything, the ap kept pumping out failure messages (i.e. this one during that time: “Sat Dec 6 03:39:07 2025 daemon.notice hostapd_s1g: wlan0: DPP-TX-STATUS dst=40:d6:3c:d9:48:1e result=FAILED”) before if finally stopped with reporting “diag_override.sh: set_state dpp_failed”. The sta displayed “diag_override.sh: set_state done” quite a while before the ap did.

The second time, ap started with “Sat Dec 6 03:43:41 2025 daemon.notice hostapd_s1g: CTRL_IFACE monitor[1]: 146 - Connection refused” right after pushing the dpp button, then nothing but FAILURE. The sta got dpp-failed a long time before the ap decided it failed, all the time pumping out those FAILURE messages.

What did I also try? Changes to the attached in :
./build_dir/target-mipsel_24kc_musl/hostapd_s1g-1.16.4/src/ap/dpp_hostapd.c
./build_dir/target-mipsel_24kc_musl/wpa_supplicant_s1g-1.16.4/src/ap/dpp_hostapd.c
This was from a suggestion from silex in 2.6.6 that helped get dpp working consistently. But…dpp in 2.9.3 still failed. I was hopeful at first b/c dpp connected, but failed the next time so I’d say these changes really didn’t help. In the file, note where I’ve commented the changes with “silex” to see what had been suggested in 2.6.6. (your system wouldn’t take .c file, so changed to .txt)

dpp_hostapd.c.txt (114.2 KB)

ACTION ITEM? For the sake of efficiency relative to time zones and back and forth exchanges of trying things, our hw guy Justin said we could send you boards so you can see in person what we are seeing here, if it would help. I could send you images to load and of course you can do your own builds if necessary if I distclean and send you the project (filemail or wetransfer). Would that be a viable option? And is this forum the only way to communicate with you folks, i.e. sending images, is through this forum? If doing this is a possibility, it would be better for Justin to handle the logistics with y’all and he has various contact info with some of your folks like Zandr and others, just let me know who he should contact to arrange that.

  1. I put “CONFIG_PACKAGE_morse-fw-6108=y” in boards/hlk-7688a/target_diffconfig. Is that not the board definition?

  2. I initially do the command “./scripts/morse_setup.sh -i -b hlk-7688a -x dev” to get devmem built into it. Is there anything else I need?

  3. I’m using the luci-theme-morse b/c that’s what we started with in 2.5.3 since it had the overall look/feel to accommodate our branding, I carried it to 2.6.6 in that upgrade and now 2.9.3. See the picture. So that would require re-addressing using the argon directories and going in and changing that stuff which I wanted to minimize changes to 2.9.3 for matter of time. It hasn’t been a trivial upgrade as it is with coordinating against things that changed. What I’m looking at next is why the halow SSID and passphrase isn’t populating in the wizard initially like it does in 2.6.6 for the changes I made to do that; those fields are currently blank.

BTW, when I uploaded that image, I used the ‘upload’ icon above and it embedded it as an image in this text note. When I uploaded logs for Lyall in the previous note, it simply put the filename as a hotlink to the file. What controls whether it embeds the file in the note here as it appears vs it putting a link to the file?

WIZARD HALOW CONNECT form: What is it that populates these fields in the wizard? Meaning, which file do I change to set the default values because once you set them in the wizard the first time, they are there. I figured it out for 2.6.6, but can’t figure out in 2.9.3.

I found that this page defined in ./feeds/morse/luci/luci-app-ekhwizards/htdocs/luci-static/resources/view/morse/wizard.js, which changed from 2.6.6. For 2.6.6 I had made changes in ./feeds/morse/netifd-morse/lib/wifi/morse.sh, which populates the SSID field with “MorseMicro” in the original code, but I changed to our desired name and it worked fine.

When I load a new image and am in the ‘Select a Wizard’ page, when I do ‘uci show wireless’, it actually does show what I changed things to in morse.sh:
wireless.default_radio1.ssid=‘NexcommAP’
wireless.default_radio1.key=‘’
But it doesn’t populate these in the station “Connect to a HaLow Network” page fields shown above.

When I enter “testssid” and “testkey2” for the 2 fields and finish the wizard, uci show wireless has those values:
wireless.default_radio1.ssid=‘testssid’
wireless.default_radio1.key=‘testkey2’
Then, when I pick wizards from the menu again, that page shows these values. Why can’t it do that from a first time run of the wizard?

As for the AP, it doesn’t work right either, but it’s different. In this case, ‘uci show wireless’ shows the items I entered for building the image, as above, however, it populates the following in the fields for the “Setup HaLow Network - AP” page the first time through:
SSID: “ep-halow-481e-ap” <===== this is the hostname, it should be “NexcommAP” from above
Passphrase: this is actually the key value from above, so that’s good.

How do you get these fields to populate properly the first time you go through the wizard?