Sdk 2.9.3 changes from 2.6.6

General
1

Some questions coming. First, for the BTN_0. For 2.6.6, it’s modified as below. Button < 5s, start dpp, >=15s do factory reset. I see a couple of new states and way to do stuff in the 2.9.3 version in: ./feeds/morse/hardware/morse-modeswitch-button/files/etc/rc.button/BTN_0.

Other than using “ubus call dpp push_button” in 2.9.3 in place of the 2.6.6 “/morse/scripts/dpp_start.sh”, is there anything I need to be aware of?

I see there’s a call to persistent_vars_storage.sh to set mode as STA or AP. Can you explain how that works?

We are using a file called ‘reset’ instead of BTN_0, some of it is below (I couldn’t find an attach file for creating a new topic and sorry, I didn’t know how to format):

OVERLAY=“$( grep ’ /overlay ’ /proc/mounts )”

case “$ACTION” in
pressed)
[ -z “$OVERLAY” ] && return 0

return 15

;;
timeout)
. /etc/diag.sh
set_state failsafe
flash_factoryreset
;;
released)
if [ “$SEEN” -lt 5 ]
then
echo “DPP Button pushed, please wait…” > /dev/console

	#for sdk 2.6.6
	/morse/scripts/dpp_start.sh
	
	#for sdk 2.9.3
	ubus call dpp push_button

if [ “$SEEN” -lt 1 ]

then

echo “REBOOT” > /dev/console

flash_reboot

sync

reboot

elif [ “$SEEN” -ge 15 -a -n “$OVERLAY” ]

elif [ "$SEEN" -ge 15 -a -n "$OVERLAY" ]
then
	echo "FACTORY RESET" > /dev/console
	flash_factoryreset
	jffs2reset -y && reboot &
fi

;;
esac

return 0

2

The code you’re looking at here is related to how our HaLowLink devices function. If you’re not using HaLowLinks, I would not recommend including this package or even trying to figure out how it works (I mean, I’m not stopping you, but I don’t think it’s useful for your use case). This package is only included in our HaLowLink builds.

What might be slightly more relevant to you - but still somewhat specific to our devices - is the reset_override script:

This works because we’ve modified the original reset script (in https://bitbucket.org/morsemicro/morse_openwrt/src/morse-main/package/base-files/files/etc/rc.button/reset) to pick up reset_override if it exists. This means we can easily change the role of an existing reset button for specific devices without having to modify the DTS.

3

Next question:

what is the difference between these 2 directories below? I have to modify mt7620.c to make sdio work for our board and it’s the same file in both paths. In 2.6.6, there was only one instance of it, at ./build_dir/target-mipsel-openwrt-linux-musl_musl/linux-ramips_mt76x8/linux-5.15.150/arch/mips/ralink/mt7620.c

- 2.9.3: ./build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/linux-5.15.167/arch/mips/ralink/mt7620.c

- 2.9.3: also ./build_dir/toolchain-mipsel_24kc_gcc-12.3.0_musl/linux-5.15.167/arch/mips/ralink/mt7620.c
4

FW Update questions:

In 2.9.3, for the image I built, when I go to fw update, it’s telling me with the red banners it doesn’t like the checksum and I have to pick ‘force update’. Any ideas what causes that? (msg displayed in yellow background is: “OK chain_verify: certificate expired Image check failed. The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform and haven’t decompressed the image before uploading.” This is followed by msg in red background: “Image check failed: OK chain_verify: certificate expired Image check failed.” which has the ‘force upgrade’ red box right below that)

Then, when I initiate it, the web page refreshes back to the home and there’s no indication the fw update has started. However, I see in my debug serial port console that it is updating. Any ideas on why it’s not giving any indication to the user?

5

in 2.6.6, I changed line 334 of ./package/base-files/files/bin/config_generate (uci -q set “system.@system[-1].hostname=$hostname”) to alter the value of hostname, like: uci -q set “system.@system[-1].hostname=$hostname-myname”. (Just so you know, I didn’t change that file, I put it in ./files/bin/config_generate). When the firmware was loaded and the first screen came up to set hostname, it would show this. Now, although I’ve done that for 2.9.3, the hostname that comes up on the webpage as the default is “OpenWrt”, instead of the hostname it puts together, which in our case would be something like “ep-halow-3341” (last 4 of the mac, I suppose). “OpenWrt” is the value on line 314. What this tells me is that ‘if’ block with my change isn’t going through that path on 2.9.3. I just confirmed that by changing “OpenWrt” to “Open-Wrt” and that’s what showed up in the hostname of the Welcome! screen.

But, after I built 2.9.3 just as a baseline using halowlink1 as the initial setup, then before I built, I went into make menuconfig and changed the device to be hlk-7688a, although the initial wizard and welcome screen didn’t come up, it set the hostname on the System Properties screen to hlk-7688a-481e. That’s what I was expecting so see, but in the form above (ep-halow…).

What am I missing in porting from 2.6.6 to 2.9.3 that it’s not going through that ‘if’ block to give me the hostname with my mod? fyi, I may certainly have more similar questions in this port of the upgrade.

6

in 2.6.6 I could set the halow SSID and passphrase to autopopulate it when the wizard shows that screen when I’m going through setting up client, but I can’t find where that is in 2.9.3. Currently it comes up blank, but I can’t find the file that sets it. On the ap wizard, it comes up OpenWrt with the passphrase I’d set up in a file.

In 2.6.6 I used the file ./files/etc/wifi/morse.sh to change ssid and passphrase as well as files/etc/uci-defaults/98-morse-wireless-defaults where I changed the passphrase, but didn’t change the ssid because the ssid should already have been what I expect from an above note where it set hostname to “OpenWrt” and didn’t take the ‘if’ path of that file to set it otherwise.

Any idea about these?

7

In 2.6.6 when dpp failed, it basically finished its processing right away and you could dpp again. In 2.9.3, I figured out how to make my led blink during dpp like 2.6.6 does. When dpp button pushed, the dpp states go through diag_override.sh (set_state). set_state gets dpp_started. I added code to start slow blink. Then if dpp fails, set_state gets dpp_failure and I added code to do fast blink. Unlike 2.6.6 which almost immediately then shows a solid red led, 2.9.3 takes a long time before it does the next state of ‘done’, which then gives the solid red. What is it doing for probably about two minutes between dpp_failure and done?

8

I can’t edit my previous question, so this is follow-on to firmware update screen in 2.9.3. When it asks to force upgrade b/c something isn’t right, this is what’s displaying in the yellow box:

“Cannot open file ‘/etc/opkg/keys/867de7e078e12c87’ for reading Image check failed.
The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform and haven’t decompressed the image before uploading.”

Here’s the thing: that file is on the device when I load my 2.6.6 image, but it isn’t on the 2.9.3 image

firmware upload screen with issue
firmware upload screen with issue600×531 109 KB

firmware upload file issue
firmware upload file issue566×308 17 KB

UPDATE: for some reason, I’m not getting that force upgrade anyway screen. I’ll keep this post, but don’t worry about this until further notice.

UPDATE 2: it did it again when I updated fw, msg was: “Cannot open file ‘/etc/opkg/keys/368ae62b2b0cfa34’ for reading Image check failed.”

9

Hey, guys. The whole reason we are going to 2.9.3 from 2.6.6 is because of the dpp work y’all did, where you said it should fix the issues we see: 1) when if station fails, it’ll usually keep failing until power cycle and 2) if you can do dpp 6x but after that, it doesn’t work. (i.e. change ap’s halow ssid and dpp to reconnect halow).

I have the majority of things cut over, but DPP isn’t working. I do the dpp button on ap, then on sta and it fails every time. I know we need to go through some diagnostics, so if you can work with me here and I’ll provide logs or whatever, we really need to do this expediently. I have the bcf from silex and all the sdio stuff appears to be running as it was on 2.6.6 (I get the flurry of driver messages with “morse_sdio mmc0:0001:2:”.

I have a number of other issues I’m trying to deal with, too, like my /etc/init.d/hostap-leds service doesn’t seem to be feeding clientconnected.sh the AP-STA-CONNECTED/DISCONNECTED events. This is being done the same way as in 2.6.6. I’ll leave the other issues separate for now, let’s just focus on this and the important dpp items in this note for now. My code comment on this issue:

#this is enabled and started in /etc/rc.local, which does stuff after boot done
#and is used to replace the command “hostapd_cli_s1g -i wlan0 -a /lib/functions/clientconnected.sh”
#which processes events like AP-STA-CONNECTED and AP-STA-DISCONNECTED
#the commands there are: “service hostap-leds enable” and “service hostap-leds start”

10

Hi @don.baker

Without seeing all the changes you’ve made, I would be guessing that something in this file is creating an empty hostname. That file should be building the prefix and suffixes from devicetree and/or your .config. Feel free to share those.
I note for the suffix it expects the explicit existence of an eth0.

@james.haggerty will correct me if I’m wrong, but I believe this is actually better reflecting the session timeouts built into the implementation of upstream supplicant (120s). If dpp fails, any subsequent press within that session would also fail. James has left some questions to the maintainers here: DPP push button timeouts/sesson-overlap interaction

Out of interest, which channel is your AP configured for? Do you have more success when using a different channel?

Can you enable debug logs on hostap and wpa_supplicant for the AP and station devices? You can do this in uci by adding option log_level '0' into the wifi-device section of /etc/config/wireless. Then recreate the bug.

11

Arien - I’ll reply to items in this note as I get to each response. The hostname issue: the board.d/00_system file is in the project, however it’s not in the built image. Neither is it in the built image of the baseline I built which was using one of the sdk’s supplied boards from the setup then changing the processor to hlk-7688a in menuconfig before the build. Here’s the thing with that: that image actually shows the hostname as “hlk-7688a-481e”, not “OpenWrt”. So now I have to figure out why that is. Would you know offhand? I was going to compare the .config files from each project, but I don’t know what would make the baseline have a hostname that’s not “OpenWrt”.

In the .config for the project I’m trying to work in, I have the following like in the 2.6.6 .config:

CONFIG_VERSION_DIST=“ep-halow”
CONFIG_VERSION_PRODUCT=“ep-halow”

Thus, I would expect the hostname on the very first wizard page where you pick the region to have been something like:

“ep-halow-481e”

Here’s another thing. In the baseline project, its .config has:

CONFIG_VERSION_DIST=“OpenWrt”
CONFIG_VERSION_PRODUCT=“”

So, trying to figure out why it does what I expect in the baseline build, but not in my project build.

Also need to figure out why even the baseline image gives that “Force Upgrade” window. Its message was: “Cannot open file ‘/etc/opkg/keys/b5b5ca10eccd0925’ for reading Image check failed.” That key file is not in the /etc/opkg/keys dir.

12

FW Update process. When you do firmware update, 2.6.6 web page would go away b/c it started shutting things down pretty quick. For 2.9.3, it takes a while (console debugger doesn’t show any activity for at least 15 secs) for it to start shutting down processes. During this time, the user has no idea because after the user starts the fw update, it goes to the home web page. Isn’t there some mechanism to give the user a different web page to let them know things are in the works and just wait? When I did fw update using the baseline image w/ openwrt2020 theme, it gave a splash screen that fw update was in progress, then about 5 secs later it went back to home screen. I don’t see even the splash screen in my project build.

13

DPP still not working after changing bw and channel. I was using bw 8, ch 28. Switched to bw 4, ch 24. Both fail dpp. Per silex, I changed ./feeds/morse/essentials/morse-regdb/artefacts/repo_channels.csv as follows, which worked in 2.6.6:

for 7688, due to silex disabling certain channels in their bcf, we have to disable those so they don’t appear to the user. Silex response: "…disabled by BCF file. The radio certification did not pass that frequency.” Channels not avail:
1MHz: 902.5 (ch 1) and 927.5 (ch 51)
2MHz: 903 (ch 2) and 927 (ch 50)
4MHz: 906 (ch 8) and 926 (ch 48)
8MHz: 924 (ch 44)
For all regions, these are disabled by setting the usable_banff_c column at the far right to 0 in the repo_channels.csv file.

However, halow connects if I go to the sta web page, click the hourglass next to halow SSID, pick the ssid it finds, then submit. Problem is some led functionality changed, so in this case it’s making my led be purple instead of blue, thus keeping red on. However, if I boot the sta from power up, the led will be blue, so that’s something else I’ve got to hunt down.

14

Ignore this now, I got a note from silex of how to handle this by making an addition in 2 dpp_supplicant.c files in routine wpas_dpp_presence_ann_channels

15

Arien, back on 12/11/2024, you provided a script to help me get notification when AP-STA-CONNECTED or AP-STA-DISCONNECTED occurred so I could do processing based on those events. The topic is here: **Visit Topic (**GPIO LED control - #17 by ajudge).

That was for 2.6.6, but it’s not doing the same thing in 2.9.3. It’s not sending anything at all to the ACTION_SCRIPT.

In /etc/rc.local, I have these, which I have echo’s in hostap-leds to verify it is doing something:

service hostap-leds enable
service hostap-leds start

I basically need to know on the AP when those events above happen. I don’t know what changed in 2.9.3 that I can’t use the ones that worked in 2.6.6, so I would appreciate some guidance. But maybe this is it: there is no file in this line defined by this in 2.9.3: PROG=/sbin/hostapd_cli_s1g. It’s in /usr/sbin/hostapd_cli_s1g. Would that be it?

16

That file is all I can see which has changed in our handling of hostnames on our fork of OpenWrt. It’s possible other systems are creating /etc/board.d files which are adjusting the hostname, or possibly/etc/uci-defaults. These files sometimes live in target/linux/ folders of the buildsystem.

The only thing I can think of to explain this is that the openwrt buildsystem has pulled in a different keyring to your previous build. On a 2.6.6 system without these keys, what happens if you run opkg upgrade openwrt-keyring before upgrading the image?

I would say so, we did move the binaries to a “better” location (at least a more consistent one with other binaries installed by openwrt)

If possible, can you share this change here? I’m interested to know why dpp wasn’t working for you on 2.9.3

17

(updated: for the force upgrade screen, sometimes it shows it, sometimes it shows the normal screen with only the 3 checkboxes)

This addresses the last 2 items on the previous reply:

a) I changed the dir in hostap-leds and the ap got the notifications which went through the ACTION_SCRIPT.

b) The last item, while dpp worked the first time I used the below code, I rebuilt the project again for the hostap-leds above and now dpp is failing again. Here’s the code that was added to the following 2 files:

./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
***Make sure to 'touch' these files to make sure they get compiled

   - in routine wpas_dpp_presence_ann_channels:
   
		if (chan->flag & (HOSTAPD_CHAN_DISABLED |
				  HOSTAPD_CHAN_RADAR))
			continue;

#if defined(CONFIG_IEEE80211AH)
//-------------------------------------------------
//mod per silex
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)
18

A correction to this, and I might need to do some experiments, but the other possibility is that the morse-firmware-sign package was added to 2.9.3. I didn’t think this would be triggering a warning when upgrading from 2.6.6 but you could experiment by removing this package.

19

Arien, this only happens intermittently when simply upgrading with 2.9.3 already loaded. Sometimes you’ll see the force upgrade screen, other times I see the normal screen. When I have 2.6.6 loaded, there has not been a problem going to another 2.6.6 or 2.9.3. This is interesting: Even just now, I have 2.9.3 loaded. I had selected a version to load, after it verified, it gave the normal screen. I didn’t do the final step to burn the image, I realized that wasn’t the image I wanted, then picked another image. When it finished loading and verifying, it gave the force upgrade screen. So until we figure it out, it “seems” random???

20

HOSTNAME issue: I built a new image from scratch. I chose the halowlink1 board. In menuconfig I changed processor to our hlk-7688a, plus the board.d network file for lan ports so I could talk to it. When it loaded, it obviously didn’t go to wizard screen, but in the status page, the hostname is “hlk-7688a-481e”, not “OpenWrt”. Thus, I’m wondering: what is the difference in this image vs the one I’ve been trying to work with? I can’t tell from .config file, is there something else that controls that?