Removing WiFi settings from octopi-wpa-supplicant.txt does not disable WiFi

[lnlp]

OctoPi version 0.17.0

Problem:

When removing previously added WiFi settings from /boot/octopi-wpa-supplicant.txt to disable WiFi again, the WiFi gets not disabled.

Settings from octopi-wpa-supplicant.txt appear to be synchronized with /etc/wpa_supplicant/wpa_supplicant.conf but in an inconsistent and unpredictable way.

Removing the settings from octopi-wpa-supplicant.txt does not remove them from /etc/wpa_supplicant/wpa_supplicant.conf. After removing the settings from octopi-wpa-supplicant.txt and booting octopi, it still connects to the previously configured WiFi network.

I hoped that raspi-config could shed some light on the issue and that I could disable WiFi via raspi-config instead, but raspi-config showed no configured WiFi network that I could remove and did therefore not help me to disable WiFi either.

I had to manually delete /etc/wpa_supplicant/wpa_supplicant.conf to get WiFi disabled again.

For the user it is not clear how WiFi needs to/can be disabled again.

Expected behavior:

• When WiFi settings are removed again from octopi-wpa-supplicant this should be properly synced with /etc/wpa_supplicant/wpa_supplicant.conf so that WiFi gets properly disabled again (I have tested removal only).
• Properly document the behavior so that the user is not left in the cold, wondering why WiFi still connects after having removed the settings from octopi-wpa-supplcant.txt again.

If standard behavior gets abstracted away from the user, the abstraction should at least behave consistently and its behavior should be documented.

Questions:

• Why is octopi not using Raspbian's standard wpa_supplicant.conf mechanism and does it use a custom octopi-wpa-supplicant.txt file on the /boot volume instead?
• Why is octopi-wpa-supplicant.txt not automatically removed from the boot volume after booting (just like Raspbian does with wpa_supplicant.conf).

_With Raspbian's standard behavior it is at least clear that after booting wpasupplicant.conf is no longer available on the microSD card (boot volume) so to disable WiFi one has to look for the file elsewhere. With octopi the user gets fooled by octopi-wpa-supplicant.txt because removing WiFi settings from it does not disable WiFi at all, while the user initially had to add the WiFi settings to this file.

[guysoft]

Hey, If I would have to guess, I would think that you used the Raspbian way, aka placing the file wpa_supplicant.conf in /boot that then gets copied. If you do that it breaks the octopi-wpa-supplicant.txt symlink and might cause strange behaviour. Please avoid doing that.

Let me explain the situation -

The way it works in OctoPi/CustomPiOS: /boot/octopi-wpa-supplicant.txt is a symlnk to /etc/wpa_supplicant/wpa_supplicant.conf Code that does that is here: https://github.com/guysoft/CustomPiOS/blob/devel/src/modules/network/start_chroot_script#L41

One more thing that is done is removing the country disable setting. The code for that is here: https://github.com/guysoft/CustomPiOS/blob/devel/src/modules/network/start_chroot_script#L31

The way it works in Raspbian: You have to manually write a file wpa_supplicant.conf and place it in /boot. If that file is there it vanishes from the folder and is copied over on to /etc/wpa_supplicant/wpa_supplicant.conf deleting the symlink there. Messing up the OctoPi way to set things up. Why is that? Because the Raspbian way was released after OctoPi was introduced. And I haven't found a way to have them not clash.

Why I am keeping the OctoPi way (answer to your question)?

1. Users are used to it and I rather not break compatibility
2. I think its not intuitive to write a file, without any example unless you go online, to set up the wifi. You are most likely to make a mistake and for the wifi not to work, and you can't debug what you did wrong because you can't connect to your Pi. And the file vanishes and you can't go back to see what you even did in the first place.
3. What raspbian did is not a standard, its something they did on their own without talking to any other open source project. When we already had a decent way to do it (IMHO better). They don't release any beta or release candidates for anyone to comment and we tried to talk to them and got a big no. Its not the only thing they have broken and I would love to advise them what to do in the future. We even had issues discovered here before they did with their own images (eg this issue ).

I would gladly welcome a PR or solution that would have both methods work.

[lnlp]

Thanks.

If I would have to guess, I would think that you used the Raspbian way, aka placing the file wpa_supplicant.conf in /boot that then gets copied.

As far as I can remember I did not. I have edited octopi-wpa-supplicant.txt to add a WiFi connection. Days later I removed the settings from octopi-wpa-supplicant.txt again expecting that it would properly synchonize those settings to wherever required. But it did not and I had to go search how to disable WiFi again.

My assumption was that OctoPi is Raspbian based.

I think its not intuitive to write a file, without any example unless you go online, to set up the wifi. You are most likely to make a mistake and for the wifi not to work, and you can't debug what you did wrong because you can't connect to your Pi. And the file vanishes and you can't go back to see what you even did in the first place.

Raspbian is the defacto standard OS for Raspberry Pi's (but is of course not the only one possible). How Raspbian uses wpa_supplicant.conf in /boot is known common practice for many Raspberry Pi users. The behavior is documented and because the boot partition is a FAT partition that can be used on any computer it is very easy to add wpa_supplicant.conf again if required.

As for "without any example": a file example-wpa_supplicant.conf can be easily added to /boot and included with the distribution and it will not get automatically deleted also.

Maybe OctoPi used octopi-wpa-supplicant.txt first before Raspbian used /boot/wpa_supplicant.conf, but in most cases people already have experience with Raspberry Pi while they have not yet with OctoPi. It is better to build on existing 'collective memory' in that case and use what is common on Raspberry Pi. Wouldn't it be more practical to synchronize/adapt how things work standard on a (Raspbian) Raspberry Pi than to keep alternate solutions in place that are familiar to existing OctoPi users only and which can easily break and cause problems when users do things to enable WiFi that are common practice on Raspberry Pi and most of them are already used to?

[guysoft]

@lnlp

As far as I can remember I did not.

Ok, then I am not sure how to help without knowing what you did - does it work with a clean install?

Raspbian is the defacto standard OS for Raspberry Pi's

That may be, but Raspbian, and really its the Raspberry Pi foundation, are not following standards in place that they should. The fact they branched off this week from Raspbian and are maintaining their 64bit custom Debian is an indicator for this. They even are not working with Rapbian anymore. Raspberry Pi foundation also forked the Linux kernel and are working in a non-starndard way. This is something even OrangePi and other Chinese manufacturers are doing and are supporting mainline kernel. Since they are not following any standard and they have nor do they document or update before releasing, I can't rely on them keeping it that way. It might change tomorrow. Furthermore, the current standard way to set things up today is cloud-init. Which RaspberryPi did not adopt. Ubuntu, for example, did adopted it in their RaspberyPi distro. If the Rpi foundation adopt something that is an industry standard, such as cloud-init. Then I would consider moving with that.

It is better to build on existing 'collective memory' in that case and use what is common on Raspberry Pi.

Keeping reverse compatibility is indeed important, and when the Rpi foundation adopt a standard and stick to it, we will support it. For now they are not. Thats my final word. Closing. If you want to continue asking other stuff you are welcome, but saying we are not to standard when its the Rpi foundation that are changing stuff on their own and not following a standard just means you are not aware of the current industry standards.

[lnlp]

but saying we are not to standard when its the Rpi foundation that are changing stuff on their own and not following a standard just means you are not aware of the current industry standards.

"just" is used incorrectly as 'proof of' here.

I sense a sensivity and frustration towards the Raspberry Pi Foundation. This may either be valid or not but I have no experience with that. My feedback is purely from perspective of an experienced Raspberry Pi user who runs into a strange (for Raspberry Pi / Raspbian uncommon) issue with WiFi.

There is one thing that is sure here and that is that octopi-wpa-supplicant.txt is not a (defacto) standard but an implementation that is custom for OctoPi (and so is the issue I experienced).

But being custom is not the problem. The real problem is that placing wpa_supplicant.conf in /boot (the FAT partition) - a mechanism that many Raspberry Pi users are used to, breaks the custom OctoPi system for configuring WiFi settings which then fails.

Placing wpa_supplicant.conf in boot is apparently a feature standard supported at kernel level or at least in the Linux distrubution that is part of the OctoPi image. Why then use octopi-wpa-supplicant.txt that is brittle and is easily accidentally broken because of standard behavior built-in to the kernel/distribution?

If the distro that is shipped with OctoPi contains any new (kernel) changes, it is common practice that these will be the new standard (for that distribution) whether official standard or not. I therefore don't see the problem of using wpa_supplicant.conf as implemented by the distribution and don't understand the reasoning of why it is not used.

I posted this feedback so it may help others and hopefully results in further improvements.

To test again I would have to redo from scratch. That is too much effort for me. It will not change my current installation and it will have no impact on the underlying cause (because according to your words this is caused by the Raspbian Foundation not sticking to standards, but neither is OctoPi's custom implementation). If Raspbian 'sucks' then why use it for OctoPi?

[guysoft]

The reason we use Rasbian as the base image os because they also ship non-free stuff and that way I know that the image works with the latest hardware.

I am not sensitive about working with the rpi foundation. I am though frustrated. OctoPi has been running for just under 7 years, during which we have been in contact both me and @foosel asking the foundation to at least do some basic communication which has only left us out of the loop. And with the Raspberries Pi 4 we saw how other projects and pundits did get pre-release info. You must understand that after getting this level no coordination there is a reason I am saying to you: "no I am not change the way the wifi works because you want, and I am not in agreement in how Rpi foundation set theirs". If you find this does not suit you, you are more than welcome to fork the project amd maintain your own build. The project is open source and I am a 100% volunteer here. No one is paying me to maintain this. I am literally giving you my work. You can take it or leave it.

[foosel]

And let's not forget that OctoPi did headless wifi configuration before it became a feature of Raspbian. They could have used our approach, they decided to roll their own instead and made it incompatible to our's, causing us additional overhead to work around their changes (because they broke what was already the established way to configure OctoPi). Yet again.

[lnlp]

@guysoft Thanks for sharing.

I am literally giving you my work.

Sure, with all respect and thankfulness.

You can take it or leave it.

True, but that does not mean that things cannot be further improved (if/when there is time for it). (Latter statement is not exactly motivating to put efforts in providing feedback.)

[lnlp]

And let's not forget that OctoPi did headless wifi configuration before it became a feature of Raspbian.

Yes I noticed in @guysoft 's response. Cool! 😀

Kudos for all the good work!

Of course I am not aware of all the underlying details and work 'they' have caused you.

But also see my remarks/suggestions from my user perspective, I just prefer the most logical where I can leverage my existing knowledge.