Using sdk 2.6.6. On our boards, I changed halow ssid on the ap to disconnect halow. As a test, I pressed the dpp button on the station only to cause it to fail dpp. I then pressed the dpp button on the ap, then the station. It finished with a failure. The station log didn’t have the “daemon.notice wpa_supplicant_s1g[14020]: wlan0: DPP-PB-STATUS start push button PKEX responder on the discovered channel (5550 MHz)” line in it that’s always there when it’s successful. I then tried again and it worked. I did the above sequences 2x and each time after a station dpp failure when trying with the ap to connect dpp, it failed the first time, then passed the 2nd time. Why would that be? What’s different about it if the station fails by itself the first time will it fail again when trying with the ap that’s in dpp? I know in a previous reply Arien mentioned a lot of work went into dpp for the 2.9.3 sdk that should help dpp overall and it may even have something to do with this, too? But short of going to that, a) is there something I can do in the 2.6.6? b) it took some effort to port our stuff from 2.5.3 into 2.6.6 because of some architectural changes, what would I expect if we were to do the same to go 2.6.6 to 2.9.3?
Hi Don,
Without the complete logs of the interaction (ideally with the log level debug set) it’s impossible for me to tell why this is happening. However, there were multiple issues that affected DPP push button reliability in 2.6.6, so your best bet is to update to 2.9.3 as a first step.
In terms of architectural changes, there have been some, but I can’t advise on how hard it will be to adapt your setup without knowing more information. If you can give me a list of ways you have hooked into or modified parts of the system, then I can give you a rough idea if we’ve changed anything relevant, but no guarantees.
James, I replied to a response Arien made to another question, where he also said get sdk 2.9.3, but I’m replying here to you and whoever can provide that sdk to me first will be very helpful for expediency for us. I can’t find the sdk 2.9.3 on any of the morse websites. I see the 2.9.3 release note doc, but no sdk. How can I a) get it and b) where would I look otherwise?
Don
We’re now distributing the majority of our open source software via github. You can get OpenWrt here:
To get a specific version, find the appropriate tag.
Thanks. I downloaded the openwrt-2.9.3.zip, that should be the one? I also need to know what the morse driver version is so I can get the proper bcf file from silex.
I’d strongly recommend that you use git to clone the repository; I don’t entirely trust github’s repository archiving. Since when you build it will automatically go and fetch from github anyway, it’s not like you can cleanly remove the dependency.
You can check the morse_driver version (which is 1.16.4) by seeing what it builds or by looking at the morse_driver package (in the morse feed). We’re trying to encourage vendors to contribute their BCF files to morse-firmware/bcf at main · MorseMicro/morse-firmware · GitHub, but unfortunately Silex is not there yet.
Thanks, I did that. 2 things: build error and silex bcf.
What was the build error?
Thanks, I did that. 2 things: build error and silex bcf.
- If I don’t use the silex bcf for their sx-sdmah part, what problem could I encounter? They have to produce a bcf for 1.16.4 driver, which may be a week or so to get. They said it’s important to use the one they produce.
- Build error. I did all the initial instructions and used ekh-mt76x8 just to get a build started. After build error, I then did “make menuconfig” and changed target to hilink hlk-7688a. Build error. Both times using “make -j8”. Then did “make -j1”, which I normally use. Still build error. Then, “make -j1 V=s” to get the output below.
This is the log output:
luci-bwc.c: In function ‘mcs_update’:
luci-bwc.c:283:59: error: ‘IWINFO_ASSOCLIST_BUFSIZE’ undeclared (first use in this function)
283 | struct iwinfo_assoclist_entry *assoclist = malloc(IWINFO_ASSOCLIST_BUFSIZE);
| ^~~~~~~~~~~~~~~~~~~~~~~~
luci-bwc.c:283:59: note: each undeclared identifier is reported only once for each function it appears in
make[4]: *** [Makefile:2: luci-bwc.o] Error 1
make[4]: Leaving directory ‘/home/ubuntu22/SourceCode/MorseMicro/hilink7688_morsesdk2.9.3/openwrt-7688/build_dir/target-mipsel_24kc_musl/luci-mod-status/src’
make[3]: *** [../../luci.mk:357: /home/ubuntu22/SourceCode/MorseMicro/hilink7688_morsesdk2.9.3/openwrt-7688/build_dir/target-mipsel_24kc_musl/luci-mod-status/.built] Error 2
make[3]: Leaving directory ‘/home/ubuntu22/SourceCode/MorseMicro/hilink7688_morsesdk2.9.3/openwrt-7688/feeds/luci/modules/luci-mod-status’
time: package/feeds/luci/luci-mod-status/compile#0.20#0.14#0.34
ERROR: package/feeds/luci/luci-mod-status failed to build.
make[2]: *** [package/Makefile:129: package/feeds/luci/luci-mod-status/compile] Error 1
make[2]: Leaving directory ‘/home/ubuntu22/SourceCode/MorseMicro/hilink7688_morsesdk2.9.3/openwrt-7688’
make[1]: *** [package/Makefile:123: /home/ubuntu22/SourceCode/MorseMicro/hilink7688_morsesdk2.9.3/openwrt-7688/staging_dir/target-mipsel_24kc_musl/stamp/.package_compile] Error 2
make[1]: Leaving directory ‘/home/ubuntu22/SourceCode/MorseMicro/hilink7688_morsesdk2.9.3/openwrt-7688’
make: *** [/home/ubuntu22/SourceCode/MorseMicro/hilink7688_morsesdk2.9.3/openwrt-7688/include/toplevel.mk:233: world] Error 2
- it is definitely best to use their BCF. In some situations it’s possible to use a similar BCF, but you would want to use one that it close to their module design, and I’m afraid I don’t know which one that is. Do not use the wrong BCF, as it will potentially violate RF regulations and misconfigure the FEM. For bring-up, it will default to bcf_failsafe.bin, which is ‘safe’ but you won’t be able to associate. i.e. probably best to wait for Silex to test, but if they don’t get back to you raise this with us and we can see if we can offer a workaround.
- this is a sign that you’re somehow building with an old iwinfo without (APP-2787, PR #28): Increase IWINFO_BUFSIZE to handle 80211ah STA count · MorseMicro/iwinfo@37516f8 · GitHub . I’m not sure how this can happen, since openwrt/package/network/utils/iwinfo/Makefile at 2.9.3 · MorseMicro/openwrt · GitHub is pointing to a commit well after that. Is it possible you don’t have a clean build, and so have some packages/files leftover from 2.6.6?
By the way, if you want to see the logs from a particular package failure, you don’t need to run with -j1 or V=sc, but can instead look in the logs directory (this is true of 2.9, but I don’t think it was true of 2.6 as our default config was different).
For #2, I created a new directory and cloned 2.9.3 to that dir, so there is nothing crossed over from 2.6.6. I want to do a clean 2.9.3 build as a baseline before I do anything else. Is that not the way to do it?
That sounds perfect. I’m at a loss as to what’s happening here in that case. Can you find the iwinfo.h file in your staging dir, which should have the lines:
// This buffer is used for assoclist which may return 8192 stations for 80211ah
#define IWINFO_ASSOCLIST_BUFSIZE (8192 * (sizeof(struct iwinfo_assoclist_entry)))
On the build, I don’t recall the details but in the past -j8 for some reason wouldn’t always work so I just used -j1. Good idea to look at logs. Adding V=s slows the build down quite a bit I’ve seen.
File is ./openwrt-7688/staging_dir/target-mipsel_24kc_musl/usr/include/iwinfo.h but that constant is not there. The only iwinfo_assoc anything is “struct iwinfo_assoclist_entry {“. The file has a date feb 6.
Hmmm…do I even have the right branch?? Aren’t the ‘*dev” branches for development then they get merged into another, like 23.05.5? I had done the clone in my directory from the git site using “git clone https://github.com/MorseMicro/openwrt.git”
enwrt-7688$ git branch
* mm/v23.05.5
enwrt-7688$ git branch -r
origin/2.6-dev
origin/2.7-dev
origin/2.8-dev
origin/2.9-dev
origin/HEAD → origin/mm/v23.05.5
origin/lede-17.01
origin/main
origin/master
origin/mm/v23.05.3
origin/mm/v23.05.5
origin/openwrt-18.06
origin/openwrt-19.07
origin/openwrt-21.02
origin/openwrt-22.03
origin/openwrt-23.05
enwrt-7688$ git branch -v
* mm/v23.05.5 e85ae6ab87 boards: (PR #381) update version to 2.9-dev
Ah, right - you should checkout the 2.9.3 tag (or alternatively the 2.9-dev branch). I’m not sure why that isn’t the default at the moment, or what is wrong with the default; I’ll chase this up. Thanks for finding this issue.
On 2.9.3 branch. It built successfully. I’m assuming this is how it should look:
enwrt-7688$ git branch
* (HEAD detached at 2.9.3)
mm/v23.05.5
That’s right; this is normal if you’ve checked out a tag. You can create a branch off this for your own work if you want, or switch to the 2.9-dev branch.
Thanks for bringing that to our attention @don.baker !
We’ve made the 2.9-dev branch the default on GitHub now to try prevent others from hitting your issue!
I got it loaded, had to change assignment of lan port but it comes up.
A few items:
-
question: 2.6.6 after initial load it took you immediately to set region then right into wizard. 2.9.3 takes you to home screen and complains about your region not being set. I looked around, but couldn’t find where to set that. It shouldn’t have to be that hard to find, it wasn’t obvious. Where is that done?
-
Then, when I tried the wizard and selected standard wifi halow, it gave the message:
Configuration incompatible with config wizard detected (Error: No HaLow radio found). If you wish to use the wizard, you should reset or reflash your device.
- I guess I need to wait to get the silex bcf before continuing testing the baseline so it’ll get things like sdio setup for the silex halow chip? In the meantime, I was going to start porting our specific changes made to the baseline 2.6.6 into 2.9.3.
That it didn’t take you to the wizard is generally an indication that your morse device hasn’t loaded up correctly; this is confirmed by the message about the config wizard (i.e. that your halow radio isn’t found). Without seeing logread from the startup and /etc/config/wireless, it’s hard for me to say exactly what happened.