Wifi 5 GHz band is broken on default install

[bengalih]

What were you doing?

Installing fresh version of 1.10.3 to new hardware using Imager 1.8.5 following the instructions here:
https://octoprint.org/download/
Using Windows 11

1. Run Imager. Choose Pi model (in my case 3), choose OctoPi from "Other specific-purpose OS" > "3d printing" menu. Choose storage to install to.
2. Enable advanced configuration with Shift+Alt+X. Configure hostname, username/password, SSID/password, Wireless LAN Country as US, and enable SSH under Services.
3. .Click Next to install and choose to apply configuration settings

What did you expect to happen?

I expected the install to boot to the 5Ghz WiFi network I enabled in the options

What happened instead?

No network connectivity at all

Did the same happen when running OctoPrint in safe mode?

yes.

Version of OctoPi

1.10.3

The issue here has several facets, and will likely impact ALL users installing following the published directions linked above, assuming they are using a 5 GHz network (with a different SSID/key from their 2.4 GHz). The reason this occurs is first:

1. The Imager does not properly configure the etc/wpa_supplicant/wpa_supplicant.conf file. Specifically, it does not set the country to anything other than GB, which apparently limits the use of the 5 GHz spectrum. This issue is already described here:

#815

There hasn't been any traction on this in almost 2 years and it still appears to be an issue. Again, because of this, no user will be able to set a 5 GHz network since the imager will not set the country. I believe this is a problem with the Imager, and I'm not sure you can do anything about it other than updating documentation and having the OctoPrint people do the same for installation of your image.

2. The second issue, which I believe is related to your image: The wpa_supplicant.conf file is meant to be a symlink to the /boot/octopi-wpa-supplicant.txt. It is not. After installation using the above setting, the setup is using only the actual file called wpa_supplicant.conf (with the GB country set and WiFi only working if 2.4 Ghz). This means that even if one manually edits the octopi-wpa-supplicant.txt file (which all the troubleshooting steps found online say to do), it will still not work because this file is not being referenced due to no symlink.

This leaves only two options to get things working. You have to either:

A) Manually edit the wpa-supplicant.conf file with all the proper settings (or use raspi-config to do this)

or

B) Manually edit the octopi-wpa-supplicant.txt file with all the proper settings and manually create the symlink from the conf file back to the .txt file.

I'm not entirely sure why the octopi-wpa-supplicant.txt is needed/used at all and which of the two options are preferable, but I have opted for (B) for now.

Would be nice to have some official acknowledgement and updating of the documentation as this was an unnecessary 90 minute headache for a new user on a 5 GHz network.

Thanks!

[guysoft]

What version of OctoPi, you posted the OctoPrint version. OctoPi released versions go up to 1.0.0

[bengalih]

Sorry. It is listed as 1.0.0 using the Imager tool. It is the latest stable release as of today, stating a release date of 2024-11-5.

[bengalih]

I have some more info for you after testing some more with the folks in the Discord channel.
Another user had the same issue with Imager keeping GB as his country, however his WiFi 5 GHz network connected.
We narrowed it down to a channel issue.
I had my control channel hard set to 149. When the country was "GB" the network was not detected.
If I changed my control channel to anything 140 or less it appeared to work even with "GB" set as the country.
However on any channel above 140 (144, 149, 153,157...) OctoPi would not detect my 5 GHz network while set to "GB".
Setting to "US" allows me to use all the channels.

So, the reason that more people haven't seen this issue is they likely have their channels set to "Auto" which seem to usually select lower channels in the spectrum.

I will note that this was only a problem with OctoPi. When I installed the latest RPiOS from the Imager it was able to detect my network without issue. However, I cannot say whether or not in those tests I validated if the country was set correctly by the Imager. I can only say it definitively does not set it when using it to image OctoPi.

[bengalih]

Just as a final follow-up here, I reinstalled RPiOS using Imager to see if it applied the country settings since, as I mentioned above, the standard image didn't have any WiFi problems. Once again, it worked fine, however it doesn't appear to set any country configuration in either wpa_supplicant.conf (which I don't think it uses), not did I find any in NetworkManager configurations. It would seem that it uses a very different way to configure the WiFi then the OctoPrint image, so it is like comparing apples and oranges.

In summation, all the issues in my original post are still 100% valid. However, it would seem that the people this would affect might be minimal because the following would have to be true:

1. They are not using GB for their country
2. They are attempting to join a 5 GHz Wifi network.
3. That network is using a channel/band greater than 140.

(3) above might also be more nuanced. It is possible that the OctoPi drivers for the RPi 3B+, or the specific chipset within is causing some sort of conflict. It is also possible that there is some WiFi chipset incompatibility between those drivers/chipset and those with my particular ASUS router.

Nonetheless, this could all be avoided if the standard setup using Imager set the country correctly and/or the documentation was updated to detail this issue.

[guysoft]

Thats expected behavior. You need to set the country code to use channels specific to your country. see https://en.wikipedia.org/wiki/List_of_WLAN_channels

5ghz wifi will not attempt to send signals if its not set to the correct country because it can clash with radar.

[bengalih]

I understand that expected behavior is to use the WiFi bands for the selected country. That however is not the root problem described in my initial report.

The reason that the bands are not working are not because I am not choosing the proper country, the problem is that:

1. Imager is not setting the country. This is covered in Configured in Raspberry Pi Imager WiFi country "US" is ignored and instead "GB" is used. #815. As that has been open for almost 2 years without any further response it is unclear to me if see that as valid, or if it has simply been hung out to dry. It would seem such behavior would deserve to be documented beyond a stale bug report.

2. If imager is used (again, as is recommended by many tutorials out there, see below), then it breaks the link the octopi-wpa-supplicant.txt file and, as such, won't be used at all.

I understand that you are not responsible for all the information out there on OctoPi. I also suspect that over time the methods and guidance may have changed. However it would behoove all potential users to update the documentation (and perhaps work with some close partners like OctoPrint) to make new users aware of these pitfalls. While not a skilled Pi user previously, I have years of technical experience and fixing this issue wasted 90 minutes (and another 60-90 gathering specific info for this bug report to be as detailed as possible).

I've also been informed that the latest beta versions of OctoPi may utilize another method for networking that makes these problems obsolete, but as the current stable version is still affected, I feel like providing higher visibility into these issues is warranted. Perhaps you want to rename this bug to only deal with the fact that the symlink is broken by Imager? Perhaps you see no merit at all to my argument. If that's the case I hope that those users who have the same issues will find this for reference and I myself will attempt to spread the word.

Thanks for your time.

As an example the following well knowns and respected sites provide tutorials that might lead to problems because of use of the Imager:

https://octoprint.org/download/
The primary setup mechanism listed is to use Imager

https://all3dp.com/2/octoprint-setup-how-to-install-octopi-on-a-raspberry-pi/
Also recommends Imager. Does provide a section on WiFi setup editing the octopi-wpa-supplicant.txt, but this won't work as previously stated because Imager (or something else) breaks the symlink to this file.

[guysoft]

Could you try the RC2 that is out and see if it fixes it?
Since the Rpi moved to use Network Manager and it changes the whole infrastructure of how the country is set. It might solve the issue.

[bengalih]

Yes I can try - and I agree I am not likely to see the issue if you have moved off of wpa_supplicant.
Can you link me to the appropriate RC2 file?
The issue with me (and I'm sure many others) is the path we are led down is to use RPi Imager tool which provides two options:

• 1.0.0 Stable
• 1.0.0 (new Camera Stack)

Is the latter the RC2? If so I will use that one although like many users I chose to go for the stable branch so this would be an issue until the RC2 becomes the Stable. Again, I think most of these problems are with the Imager breaking OctoPi, so the best fix here is probably just insight and documentation for those users until RC2 is fully released.

[guysoft]

RC2 issue page: #842

You can also test any nightly on the rpi imager like this, should be about the same:

rpi-imager --repo https://unofficialpi.org/rpi-imager/rpi-imager-octopi.json

[bengalih]

FYI, I loaded up the nightly RC2 build this morning and it did not have the issue, as expected, because of the move away from wpa_supplicant.

I had it up for a couple of hours not doing anything other than tinkering with the basics of OctoPrint.
I began a 3 hours print job this evening and about 2 hours into it I lost all connectivity with the Pi. (3B+, brand new).

I was able to connect it up via HDMI and troubleshoot. Long story short, nothing would get the WiFi back up short of a reboot.
It looks like there were some errors in the brcmfmac drivers. I have saved off logs and have found a few mentions of similar errors online, but nothing that would seem to make much sense apart from just the Pi being a piece of junk.

I'm not sure if you can help on this, or are interested in seeing the logs. Let me know if I should open another bug with the specifics. If you are not interested, I might try to see if I can file direct with RPi. Apart from that, I am going to try some things:
If it keeps happening, I might switch to 2.4 instead of 5.0Ghz band. I also may go back to your stable release, although this appears to be lower level then NetworkManager/wpa_supplicant, so I don't know if that will matter.

I might just have to give up on the Pi and find another solution as I need to utilize WiFi.

Appreciate your time.

[guysoft]

If you found a bug in pi drivers find the relevant issue here or post a new one. They should fix it and if you have logs/reproduction steps it might help them.
The channel number and settings might help too
https://github.com/raspberrypi/linux

It might also be a parricular wifi router combination.

I have an openwrt router on 5ghz on my printer and it does work so i think its some aspect that might be the issue