# Dpp failure condition **URL:** \ **Category:** General\ **Created:** [October 22, 2025, 9:46pm UTC](https://community.morsemicro.com/t/dpp-failure-condition/962 "2025-10-22T21:46:14Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![don.baker](https://avatars.discourse-cdn.com/v4/letter/d/7bcc69/32.png) [@don.baker](https://community.morsemicro.com/u/don.baker)\ **Post date:** [October 22, 2025, 9:46pm UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/1 "2025-10-22T21:46:14Z")
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? ---
**Author:** ![james.haggerty](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@james.haggerty](https://community.morsemicro.com/u/james.haggerty)\ **Post date:** [October 22, 2025, 10:09pm UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/2 "2025-10-22T22:09:20Z")
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. ---
**Author:** ![don.baker](https://avatars.discourse-cdn.com/v4/letter/d/7bcc69/32.png) [@don.baker](https://community.morsemicro.com/u/don.baker)\ **Post date:** [October 29, 2025, 7:54pm UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/3 "2025-10-29T19:54:10Z")
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 ---
**Author:** ![james.haggerty](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@james.haggerty](https://community.morsemicro.com/u/james.haggerty)\ **Post date:** [October 29, 2025, 8:55pm UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/4 "2025-10-29T20:55:26Z")
We’re now distributing the majority of our open source software via github. You can get OpenWrt here: > **[GitHub - MorseMicro/openwrt](https://github.com/MorseMicro/openwrt)** > > Contribute to MorseMicro/openwrt development by creating an account on GitHub. To get a specific version, find the appropriate tag. ---
**Author:** ![don.baker](https://avatars.discourse-cdn.com/v4/letter/d/7bcc69/32.png) [@don.baker](https://community.morsemicro.com/u/don.baker)\ **Post date:** [October 31, 2025, 1:18am UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/5 "2025-10-31T01:18:33Z")
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. ---
**Author:** ![james.haggerty](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@james.haggerty](https://community.morsemicro.com/u/james.haggerty)\ **Post date:** [October 31, 2025, 2:59am UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/6 "2025-10-31T02:59:12Z")
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](https://github.com/MorseMicro/morse-firmware/tree/main/bcf), but unfortunately Silex is not there yet. ---
**Author:** ![don.baker](https://avatars.discourse-cdn.com/v4/letter/d/7bcc69/32.png) [@don.baker](https://community.morsemicro.com/u/don.baker)\ **Post date:** [October 31, 2025, 8:11pm UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/7 "2025-10-31T20:11:55Z")
Thanks, I did that. 2 things: build error and silex bcf. ---
**Author:** ![james.haggerty](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@james.haggerty](https://community.morsemicro.com/u/james.haggerty)\ **Post date:** [November 2, 2025, 11:32pm UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/8 "2025-11-02T23:32:37Z")
What was the build error? ---
**Author:** ![don.baker](https://avatars.discourse-cdn.com/v4/letter/d/7bcc69/32.png) [@don.baker](https://community.morsemicro.com/u/don.baker)\ **Post date:** [November 3, 2025, 1:13pm UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/9 "2025-11-03T13:13:16Z")
Thanks, I did that. 2 things: build error and silex bcf. 1. 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. 2. 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 ---
**Author:** ![james.haggerty](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@james.haggerty](https://community.morsemicro.com/u/james.haggerty)\ **Post date:** [November 3, 2025, 10:21pm UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/10 "2025-11-03T22:21:15Z")
1. 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. 2. 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](https://github.com/MorseMicro/iwinfo/commit/37516f83508b3d04f6d928d6f20550931890439c) . I’m not sure how this can happen, since [openwrt/package/network/utils/iwinfo/Makefile at 2.9.3 · MorseMicro/openwrt · GitHub](https://github.com/MorseMicro/openwrt/blob/2.9.3/package/network/utils/iwinfo/Makefile) 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). ---
**Author:** ![don.baker](https://avatars.discourse-cdn.com/v4/letter/d/7bcc69/32.png) [@don.baker](https://community.morsemicro.com/u/don.baker)\ **Post date:** [November 4, 2025, 2:42am UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/11 "2025-11-04T02:42:35Z")
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? ---
**Author:** ![james.haggerty](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@james.haggerty](https://community.morsemicro.com/u/james.haggerty)\ **Post date:** [November 4, 2025, 6:13am UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/12 "2025-11-04T06:13:07Z")
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: ```auto // This buffer is used for assoclist which may return 8192 stations for 80211ah #define IWINFO_ASSOCLIST_BUFSIZE (8192 * (sizeof(struct iwinfo_assoclist_entry))) ``` ---
**Author:** ![don.baker](https://avatars.discourse-cdn.com/v4/letter/d/7bcc69/32.png) [@don.baker](https://community.morsemicro.com/u/don.baker)\ **Post date:** [November 4, 2025, 1:00pm UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/13 "2025-11-04T13:00:24Z")
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”](https://github.com/MorseMicro/openwrt.git%E2%80%9D) 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 ---
**Author:** ![james.haggerty](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@james.haggerty](https://community.morsemicro.com/u/james.haggerty)\ **Post date:** [November 4, 2025, 9:32pm UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/14 "2025-11-04T21:32:00Z")
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. ---
**Author:** ![don.baker](https://avatars.discourse-cdn.com/v4/letter/d/7bcc69/32.png) [@don.baker](https://community.morsemicro.com/u/don.baker)\ **Post date:** [November 5, 2025, 12:30am UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/15 "2025-11-05T00:30:40Z")
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 ---
**Author:** ![james.haggerty](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@james.haggerty](https://community.morsemicro.com/u/james.haggerty)\ **Post date:** [November 5, 2025, 6:31am UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/16 "2025-11-05T06:31:48Z")
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. ---
**Author:** ![ajudge](https://avatars.discourse-cdn.com/v4/letter/a/c2a13f/32.png) [@ajudge](https://community.morsemicro.com/u/ajudge)\ **Post date:** [November 5, 2025, 9:04am UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/17 "2025-11-05T09:04:21Z")
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! ---
**Author:** ![don.baker](https://avatars.discourse-cdn.com/v4/letter/d/7bcc69/32.png) [@don.baker](https://community.morsemicro.com/u/don.baker)\ **Post date:** [November 5, 2025, 9:10pm UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/18 "2025-11-05T21:10:05Z")
I got it loaded, had to change assignment of lan port but it comes up. A few items: 1. 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? 2. 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](http://192.168.3.1/cgi-bin/luci/admin/system/flash). 1. 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. ---
**Author:** ![james.haggerty](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@james.haggerty](https://community.morsemicro.com/u/james.haggerty)\ **Post date:** [November 6, 2025, 10:06pm UTC](https://community.morsemicro.com/t/dpp-failure-condition/962/19 "2025-11-06T22:06:57Z")
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.