Am trying to figure out the DPP process and items needed.
In dts file, I have led-dpp = &led_myled;
When I setup the AP in wizard, I set the ssid to be different from the default the client is presented. It is setup as ethernet/bridge.
On the client, I chose manual not dpp and just took the default halow ssid and did not do the scan button. It is set as extender.
I see the pb in BTN_0 launches /morse/scripts/dpp_start.sh
This, in turn, launches /lib/netifd/morse/wpa_s1g_dpp_action.sh
I have some echoâs added to those files for debug to the console port
When pb pressed on ap, then client, client led starts 1s blink pattern.
wpa_s1g_dpp_action.sh started() is echoed. I see this on both the ap and client consoles.
On client it soon shows failed(), followed by finished().
Soon, the AP then shows failed() then finished().
What other things are needed to get client to connect to the ap using dpp pushbutton?
There are two known issues around DPP pushbutton (fixes will be in our next release):
- in the US region the DPP push button interaction will sometimes timeout due to the large number of channels to scan (still should mostly succeed)
- for 05US devices that have blocked channels (to optimise for US regulatory requirements) the DPP will fail when it tries to use a blocked channel
I suspect youâre affected by the latter issue. You can see if this is so by checking logread and seeing if there is an attempt to set a failed channel. In general, I would recommend going to logread before getting into hacking the underlying scripts!
Iâve attached a patch which should fix this - add this file to utils/wpa_supplicant_s1g/patches and utils/hostapd_s1g/patches and remove the existing file (which only fixed the Australian region). Note that we have subsequently cleaned up how DPP push button works, so the next release should have a much nicer experience and all these hard-coded channels are removed.
0003-Hack-out-channels-1-2-50-and-typo-for-51.patch (1.3 KB)
If you donât want to use this patch, you can also avoid this by using the AU region, as this will exclude the âbadâ channels.
1 Like
James, do you really mean to add that patch file? It contains this below when I download and didnât know if that was intentional or if it meant to update the c file it referred to.
Don
From c2b6ece1375affba47f7d94d0303dc83087ff8b7 Mon Sep 17 00:00:00 2001
James, because I noticed the errors you mentioned to look for, I did âlogread -fâ and saw where it showed: daemon.err wpa_supplicant_s1g[4410]: nl80211: kernel reports: Channel is disabled
I took the diff in that patch file and made those changes in both:
./build_dir/target-mipsel-openwrt-linux-musl_musl/hostapd-wpad-full-openssl/hostapd-2023-09-08-e5ccbfc6/wpa_supplicant/dpp_supplicant.c
./build_dir/target-mipsel-openwrt-linux-musl_musl/wpa_supplicant_s1g-rel_1_11_3_2024_Mar_28/wpa_supplicant/dpp_supplicant.c
I didnât get any channel errors, but I didnât see it succeed, either. I donât see where to attach files in this system or Iâd send the AP and client logs. Thought you might like to see what they show.
Be a bit careful make build_dir edits, since they wonât persist. Easier to just copy the patch file in if you have your own copy of the repo (you can use src-link in feeds.conf to point to a local repo - e.g. src-link morse ../../morse-feed).
I uploaded the patch by clicking the âUploadâ button in the reply (7th one across for me); let me know if you canât see it, as that may mean we have some permissions error.
Without seeing the logs, Iâm not sure whatâs going on here. It should just work. If the logs donât make it clear whatâs gone wrong in the DPP interaction, you can increase the verbosity by using wpa_cli_s1g and hostapd_cli_s1g and typing log_level DEBUG before doing the push button, but this will be very verbose.
Below is the contents of the patch file on my download of it
Log files of ap and client after pb pressed to initiate dp are attached. If your system needs the text embedded, let me know and Iâll copy the text to the reply, instead.
(attachments)
AP log after pb pressed.txt (18.2 KB)
client log after pb pressed.txt (32.4 KB)
Thatâs interesting - the vast majority of DPP packets are âresult=FAILEDâ, which makes me suspect that thereâs some comms issues between the two devices. Also odd that the AP started received on a different frequency at the end. How far away are your devices?
Can you try shifting to Channel 44 (with no prim channel width or index set) and see if itâs something to do with running close to the edge?
Also, if you could run log_level DEBUG before grabbing the logs (as described above) that would be helpful.
Just a note when I say starting dpp by pushbutton, I mean the actual pushbutton we are using, just like the tiny button on the ekh-03, not the âpushbuttonâ in luci.
James, I looked in the .config file and it had a couple of dpp related items that were specified in the morse ekh03 kit that werenât in my project. I checked those in make menuconfig, it added 2m to the image, but the dpp still didnât connect. Logs are attached.
Don
(attachments)
AP log after pb pressed after config chg.txt (44.5 KB)
client log after pb pressed after config chg.txt (45.8 KB)
Breakthrough, sort of. Hereâs whatâs interesting. I used the morse ekh03 kits to see if they would do dpp; one as ap, the other as client. They didnât do dpp, either, whether I pressed the buttons on their boxes or clicking the dpp start buttons from luci. Same thing as on our devices, even though I had put your channel changes array into the .c file to accommodate US region. Even with this mod in our device for US region dpp still didnât work. So I then reset the ekh03âs and set them to use AU region, remembering what youâd said about regions in the note above. When I pressed the buttons on the boxes, they paired via dpp.
So, I had to try that on our devices. I reset them and changed the region to AU. Then I pressed the buttons on our devices, ap first then client. The log had different stuff then started going through sd stuff, then they connected!
So that tells me thereâs something more than just that array of channels that needed to be changed. Thus, it works when region is AU but doesnât work for region US.
Any ideas what the difference is so I can make this work with region = US?
Sorry youâre having these issues, and thanks for your patience. I am surprised that the EKH03 kits consistently didnât work for you. Note that the dpp related items in the EKH03 config are to do with supporting DPP qrcodes, and should not be needed for push button.
Unfortunately, itâs very hard to diagnose whatâs happening from the logs unless you turn on the debug logging, as described earlier. In the new year (holidays for us me at the moment), I will try to find out if we can provide a patch which backports some of the changes which improve reliability.
In the near term, if you patch more of those channels out I suspect it may solve your problems. i.e. restrict it to the subset of channels youâre planning to use. The tricky part is figuring out which channel is which: youâll need to look at /usr/share/morse-regdb/channels.csv (from memory), determine the corresponding â5gâ channel, then look up the frequency of that channel. Or, possibly easier, you can set a channel on your device then look at the output of iw (which will report the mapped 5g channels) rather than iwinfo (which will report the correct HaLow channels).
If you can wait a bit longer, hopefully our next public release will be out soon.
Hi, James. Ya, I had wanted to see how the ekh03 behaved for comparison and it worked the same as I see on our boards relative to region.
Did you see in an earlier response I tried âlog_level DEBUGâ? Hereâs the result: â/bin/ash: log_level: not found. I tried loglevel also. The only log* anything in /bin is login and /sbin is logd and logread.
Is there an approximate time for âout soonâ so I can give heads-up to the owner? And what is the public release - is that the next entire openwrt sdk version or what does it consist of? If entire sdk, what surprises might I encounter relative to the various things Iâve had to do to make 2.5.3 work? I have a number of files that modify a few things, including luci. I also know from silex if morse uses a newer driver than 1.11.3 that they will need to supply me with a bcf that matches the driver.
I think the thing that went wrong with running log_level DEBUG is that this command is run after connecting to hostapd/wpa_supplicant via wpa_cli_s1g and hostapd_cli_s1g`.
I didnât realise you were using 2.5.3; it may be worth trying 2.6.6 (if you can get a 1.12 driver BCF) to see if it improves the situation. Our next public release in terms of the internal structure should not be substantially different from the existing 2.6.6 (available via github), as it will also be based on OpenWrt 23.05, but without knowing what changes youâve made itâs hard to predict what issue you may encounter.
In terms of release dates, I canât even say âout soonâ - you might notice Iâve said âhopefully out soonâ. Thereâs a lot of internal testing for each release, and I canât predict the results of that (if only!).
Hi, James. I got the current 2.6.6 from morse site and the bcf for halow 1.12 from silex. I figured out the changes necessary from our specific mods made to 2.5.3 (I keep them in a separate dir and just copy to the main project). Some files went in ok, others needed special handling due to the architecture changes in 2.6.6.
I see in 2.6.6 the s1g_chirp_channels in dpp_supplicant.c were slightly modified from 2.5.3 and almost match what youâd sent to me previously to try in 2.5.3, except for 2 channels. Using the one in 2.6.6, dpp still fails with ap and client set for the US region. However, dpp set with AU region works ok.
Is there anything you can think of to check? Would you like any logs?
Don
If youâre using 2.6.6, you will most likely need to apply the same changes to the chirp channels as I indicated before (the changes necessary depend on what module youâre using). You can check if this is the issue by seeing if thereâs an attempt to set a disabled 5ghz channel in the logs.
If itâs still not working, you can almost certainly make it work in the US region if you patch out more of the chirp channels in that same location (if you have some that youâre not planning to use; if you want the UI to be consistent, you should also remove them from /usr/share/morse-regdb/channels.csv). Alternatively, provide the debug logs and I can look into what the exact failure mode is.
I appreciate the details and other things you describe.
I had a few logs to send you but before I did, I tried a suggestion from silex and with some extra trial and error, was able to make dpp work!!! So, no logs for you.
Silex had these 2 suggestions:
5517,5519c5514
< //if (eloop_register_timeout(0, 500000, wpas_dpp_pb_next,
< if (eloop_register_timeout(0, 1500000, wpas_dpp_pb_next,
Great!
Just a warning: Iâm not familiar with it, but this may be outside the DPP spec.
I donât know if the text got lost in your forum posts, but here are the 2 items I mentioned (I didnât see all of it in the post above):
Silex had these 2 suggestions:
5517,5519c5514
â<â //if (eloop_register_timeout(0, 500000, wpas_dpp_pb_next,
â<â if (eloop_register_timeout(0, 1500000, wpas_dpp_pb_next,
was:
â>â if (eloop_register_timeout(0, 500000, wpas_dpp_pb_next,
5596,5597c5591
â<â // SK debug DPP
â<â if (eloop_register_timeout(7, 0,
was:
â>â if (eloop_register_timeout(10, 0,
For changing files in build_dir, I have a few items that need changing like ./build_dir/target-mipsel-openwrt-linux-musl_musl/linux-ramips_mt76x8/linux-5.15.150/arch/mips/ralink/mt7620.c to reflect things necessary for pin control stuff for our pushbutton and LED. I got the initial change from Zandr who got it from someone there at morse and that was the first time pin control stuff actually did what it was supposed to do. Besides just building the project and then replacing that file and rebuilding, I donât suppose thereâs a place to put our modified mt7620.c so we donât have to build the project, replace and touch that file, then build it again, is there?
Itâs surprising to me that you would need to carry kernel patches for this, but I donât have the context. However, if you want to have kernel patches for mt762x you should put them in target/linux/ramips/patches-5.15. These will be applied on every build, so you donât have to modify build_dir (in general, modifying build_dir is a hacky thing you would do for testing).
