The patch applied to mt7620.c adjusts the register which puts the mt7628 into “IoT mode” (as Mediatek describes it).
This was needed because, in this case, the bootloader used in this application was leaving the mt7628 in “router mode” which puts most pins into an analog state for additional Ethernet PHYs
Originally this register change resided in the “proprietary” MMC driver, so this issue didn’t crop up until we moved to using the Linux mainline mmc driver.
Our evaluation kits dodge the issue by having the register set in uboot.
A DPP redux: in testing, I’m having inconsistent behavior when doing dpp by pushbutton. I haven’t even exhaustively tested through various bw, ch and other scenarios, I had all these observations pretty quickly:
init ap with wizard, setting halow ssid to SSID1, bw 8mhz, ch 12. After client wizard done where I leave its halow ssid to its default so it’s different and they’ve settled post-wizard setup, I press ap dpp button then client dpp button. DPP works and connects halow. I change the ap ssid to SSID2, change bw to 1mhz, ch 3. When those changes are settled after applying, again press the dpp buttons. Failure. I change the client bw to 1mhz. Still dpp failure. I change ap bw to 8mhz, ch to 28, client bw to 8mhz ch 12. Press buttons, DPP failure. Client log shows a whole bunch of these:
while ap log is a bunch of these:
Thu Jan 16 03:24:34 2025 daemon.notice hostapd_s1g: wlan0: DPP-TX-STATUS dst=1c:bc:ec:21:64:55 result=SUCCESS
Thu Jan 16 03:24:34 2025 daemon.notice hostapd_s1g: wlan0: DPP-TX-STATUS dst=1c:bc:ec:21:64:55 result=SUCCESS
Thu Jan 16 03:24:36 2025 daemon.notice hostapd_s1g: wlan0: DPP-RX src=1c:bc:ec:21:64:55 freq=5560 type=19
Thu Jan 16 03:24:36 2025 daemon.notice hostapd_s1g: wlan0: DPP-TX dst=1c:bc:ec:21:64:55 freq=5560 type=20
T
The client log even had this, which it does when it is successful:
Thu Jan 16 03:23:48 2025 daemon.notice wpa_supplicant_s1g[14584]: wlan0: DPP-PB-STATUS start push button PKEX responder on the discovered channel (5550 MHz)
The ap log did have this a few times, wherever it got that freq from:
Thu Jan 16 03:24:08 2025 daemon.notice hostapd_s1g: wlan0: DPP-TX dst=ff:ff:ff:ff:ff:ff freq=2437 type=7
Thu Jan 16 03:24:08 2025 daemon.err hostapd_s1g: nl80211: kernel reports: Channel is disabled
Now, however, if I go to the client quick configuration page and click the magnifying glass to scan for wifi networks in the halow section, it adds the AP’s new ssid to the list. I pick it and halow then connects.
I can provide logs for the various situations above at the various stages if that helps. But even when I just change channels while 1mhz bw, always fails.
Can you help characterize how dpp should work relative to the issues in the scenario above?
if I do factory resets and in wizard set halow ssid to same on ap and client by just taking the default string, halow connects after wizard gets things settled. If I change the ap SSID by just adding ‘1’ to the end of the existing ssid and save, it disconnects halow. When I do dpp with our pushbuttons, halow then reconnects. That’s good, but I didn’t understand why it wouldn’t after I went to 1mhz and had the failures then came back to this same setup and it wouldn’t connect dpp.
Any ideas on this?
for the above, this line appears in the log when dpp works and is usually there when it fails. However, there’s a bit of a pause after this line when dpp eventually works. It still goes through various channels until it decides it’s done and will be successful, but I figured something isn’t working right when it displays that line and doesn’t have much delay until it continues when dpp fails.
Thu Jan 16 03:38:51 2025 daemon.notice wpa_supplicant_s1g[6812]: wlan0: DPP-PB-STATUS wait for AP/Configurator to allow PKEX to be initiated
While the dpp scenarios I just mentioned don’t work, if I use the luci web page on the client and pick the ‘scan for wifi networks’ magnifying glass button under the halow ssid column next to the dropdown for picking the ssid, it finds the ap’s ssid each time I’ve tried in just the few attempts on different bandwidths.
What’s the difference between how this works and how dpp works?
even using f10 on the luci page, I can’t figure out the event it executes when I click on that magnifying glass. Can you provide hints for what to look for?
(NOTE: all the dpp problems I’m having are when region is US. DPP seems to work in the small sample set across different bandwidths when region is AU. And, yes, I do have the mods in the dpp_supplicant.c files to change the channel chirp array thing)
Sorry, I haven’t had time to look into this as yet. From your report, it looks like there may be timing issues in the US issuing a DPP when wpa_supplicant is already trying to look for another SSID.
Some quick thoughts:
if it’s working in AU and not in US, it’s almost certainly down to the size of the channel chirp list (and timeout issues). To workaround this, you could remove some of the channels in that list you’re unlikely to use.
the reason it works to connect when you do it manually is because it’s doing something a lot simpler than a DPP interaction: just looking for the beacon from the new SSID and then you tell it to connect.
the magnifying glass is calling an iwinfo scan via ubus. You should be able to see this in the json-rpc calls to /ubus in the network tab, via using ubus monitor on the device while this is happening. You can call iwinfo scan yourself from the CLI by doing ubus call iwinfo scan '{"device": "phy1"}' or similar (you may have to change the phy number as appropriate).
