search

YIO-Remote / remote-os

💎 Buildroot OS for YIO remote
GNU General Public License v3.0
13 stars 9 forks source link

CH12, CH13 & CH14 are not possible to connect without setting wifi region on the pi #25

Closed carp3-noctem closed 4 years ago

carp3-noctem commented 4 years ago

During Initial Setup the Pi is not able to scan or connect to (European) WiFi that is using CH12,13 or 14. First the WiFi Region needs to be set.

zehnm commented 4 years ago

This needs an enhancement in remote-os and possibly remote-software:

Related issues: #13 Improve WiFi setup scripts

Tosko4 commented 4 years ago

Hey @carp3-noctem I don’t want to push anyone here. But I think large base of the community is european, making this setup progress for most of us harder. I know how to change channels after I was informed by Marton about this issue. But I’m sure if this is not solved in time, there will be a lot of questions asked why people can’t finish the configuration progress.

Maybe a little bit higher priority is welcome?

carp3-noctem commented 4 years ago

@Tosko4 i think @zehnm is already on a fix. He completely rewrite the whole wifi handling and has also accepted that issue. Also the setup will read the region from your device (don't know if set is already included) but at least we know how to handle the situation.

zehnm commented 4 years ago

The new WifiControl driver allows setting a country code. This 'just' needs to be called from the ui or through an API call which still needs to be done. The driver should be ready and merged in dev by the end of this week.

Other options at the moment:

martonborzak commented 4 years ago

@Tosko4 still has issues with wifi. Looks like we need to set a default country maybe on driver level, to be able to even scan for these networks.

Discussion and possible solution: https://github.com/balena-os/balena-os/issues/309#issuecomment-302057508

martonborzak commented 4 years ago

Maybe iw reg set <country code>

mKeRix commented 4 years ago

Since my WiFi normally runs on ch13 for 2.4GHz I did some more research for this. Setting country in wpa_supplicant.conf did not help, it still only connects and finds the network if I change the channel to 11 or lower.

When open a SSH session and run iw reg get I get:

global
country 00: DFS-UNSET
    (2402 - 2472 @ 40), (6, 20), (N/A)
    (2457 - 2482 @ 20), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
    (2474 - 2494 @ 20), (6, 20), (N/A), NO-OFDM, PASSIVE-SCAN
    (5170 - 5250 @ 80), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
    (5250 - 5330 @ 80), (6, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN
    (5490 - 5730 @ 160), (6, 20), (0 ms), DFS, PASSIVE-SCAN
    (5735 - 5835 @ 80), (6, 20), (N/A), PASSIVE-SCAN
    (57240 - 63720 @ 2160), (N/A, 0), (N/A)

Running iw reg set DE returns successfully with no output, running iw reg get after that just returns the UNSET output from above again though. The same happens for a bunch of other country codes that I tried. I'm not familiar with buildroot, but could it be possibly that the issue stems from the crda and wireless_regdb packages missing?

martonborzak commented 4 years ago

You might be right. I was also found that we need the crda package.

zehnm commented 4 years ago

I will test that soon, also if the changes are persisted after a reboot. According to this thread, the regulatory domain information might also come from the access point: https://www.raspberrypi.org/forums/viewtopic.php?t=147151

zehnm commented 4 years ago

Tested with country CH and channel 13:

zehnm commented 4 years ago

Fixed in latest remote-os and remote-software builds