Gluon: Add option to disable the WiFi Button

[rubo77]

I think this is on a widespread wishlist, see: https://forum.freifunk.net/t/firmware-aenderungswunsch-wifi-taste-deaktivieren/9009

in that thread there is suggested to replace the etc/rc.button/rfkill script with a replacement, but it seems not the best solution.

I think the standard-script should be modified to obey a new option like rfkillbutton.disable=1 or such.

How do you usually modify standard openwrt-files?

[NeoRaider]

I'd like to get rid of all OpenWrt patches we have at the moment, so we must find a way to do these changes in a way acceptable for LEDE (at the moment, we also have a patch in Gluon that disables the factory-reset feature of the reset button, which is a similar issue).

Having a way to disable these features in /etc/config/system would be nice, I will probably write a patch for LEDE eventually.

[Kunsi]

Even better: make the function of this button configurable somehow. I have some nodes which disable client wifi during specific daytimes, would be nice to have the wifi-button just enable/disable client wifi.

[christf]

@oszilloskop I thought you might be interested in this.

[viisauksena]

in case u need a quick solution : wifi up is what you want, maybe as crontab
more info (as suggested above): here

and surprisingly right now: https://forum.freifunk.net/t/firmware-aenderungswunsch-wifi-taste-deaktivieren/9009/25 a special package done by @oszilloskop to configure wifi button
https://github.com/freifunk-ffm/packages/blob/master/ffffm-button-bind/files/etc/rc.button/rfkill.btnb

[rubo77]

We worked a bit more on the package
https://github.com/freifunk-ffm/packages/blob/master/ffffm-button-bind/

[rotanid]

@rubo77 is this package tested with v2017.1.x or v2016.2.x or both?
maybe this package could be added to gluon with a PR?

[rubo77]

It works in 2016.2.x.

In 2017.1 out doesn't work correctly. See https://github.com/freifunk-ffm/packages/pull/33

[rubo77]

in 2018.1.x and current master it works fine

[rotanid]

the old version or some fork?

[rubo77]

https://github.com/rubo77/ffm-packages

[rubo77]

Works fine in 2018.2 too

[kevin-olbrich]

@rotanid
maybe this package could be added to gluon with a PR?

@rubo77 What do you think? This issue is part of a milestone ("next") and it might fit into 2019.1 because it does not need much work to get it included.
The only thing that might be missing is an option to setup the default value using site.conf.

[rubo77]

@kevin-olbrich maybe you can add a PR that adds this to gluon? I have so many other PRs running atm. and I will be a father soon, where I will have less time ;)

I can review your PR then (I have added you as Collaborator in my Repo)

The only thing that might be missing is an option to setup the default value using site.conf.

I don't think this is needed, because a default value of 0 (= button disabled) is what people want. Usually, there is no need for a Wifi Button that turns off the Wifi on a Mesh node. (A mesh node with Wifi turned off has the same effect as a completely turned off mesh node, so you could just use the switch instead)

There are some open issues, not sure how important each, but check those: https://github.com/rubo77/ffm-packages/issues

[rotanid]

i don't think this is in its current state good enough for upstream.
i include it in our newest firmware (still in experimental) but adjusted it to make it more user-friendly, i.e. it does not disable the button for people who seem to use it (= where wifi is currently disabled)
and apart from this, it will most certainly not reach 2019.1 as this is coming very soon

[Adorfer]

the issue with wifi-button i have is that pressing it causes (as far as i see) a commit/flash write, since the button-press has to be made reboot proof.
So on a long run this can cause deteriorated overlay-fs, resulting in the situation that fs becomes ro and no uci commits possible any more.

[kevin-olbrich]

@Adorfer I have a lot of nodes with OpenWRT that change a lot using UCI. This is also the case with the LuCi web, when chaning the network settings. Why do you think that the overlay will get RO? I never had such a problem in the past.

[rubo77]

The flash write would only be a problem if it happened periodically 1000 of times.
This package just write one time and only in some modes

[Adorfer]

Why do you think that the overlay will get RO? I never had such a problem in the past.

We had dozens of 841/1043 devices with r/o filesystems, resulting to UCI-errors etc.
those were always mounted in public spots like washing rooms or kitchens of refugee homes. They got their uplink wired from the roof via some Nanostation.
when we observed "no clients for longer time" there was an expect-script checking for "wifi disabled?->renable". And these ran frequently....
so perhaps there was an issue on 2016.2, or people triggered the button and powercycled at the same time? We do not know! off course uplinks were sometimes flaky, sometimes perhaps people unplugged to get their children to do homework? We do not know! We just see that "wifibutton in public spaces": Bad idea. (And we did not observe this EVER with units which were inaccessible, e.g. due to "mounting above ceiling or behind permanently locked door)

BTW: Recovery was always via "sysupgrade -n" with a "bypass-configmode"-firmware.
(This is just the explanation why we believe there is an issue and why such a function is neccesary)

@rubo77 This is NOT claiming that the actual SPI was damaged, i just state that the overlayFS was corrupt.

[rubo77]

Maybe we should add a minimal package, that ONLY disables the wifi-button

[kevin-olbrich]

Maybe we should add a minimal package, that ONLY disables the wifi-button

Sounds like a good idea, this could be extended easily later.
As soon as I have finished a larger rollout, I will start working on this.

[Adorfer]

minimal package, that ONLY disables the wifi-button

a simple site.conf-option would do for us.

[rubo77]

You wouldn't need an option. If you include the package, the button is disabled

[Adorfer]

i would preferr to have the config in the site.conf and just the make-basics in the site.mk (hence: the triplet of modules, site.conf and site.mk is already not ideal in my view, a unified conf, perhaps with the possibilities of include files would be appreciated, but that's another topic)

[kevin-olbrich]

You wouldn't need an option. If you include the package, the button is disabled

Please also keep multi-domain in mind. There might be cases where only some of the domains want the button to be disabled (for example public area) or enabled (home setup). Packages included in site.mk will be available to all domains but without the switch, you have a full or nothing scenario.

The default can still be "button disabled", just like the VXLAN-mesh switch.

[rubo77]

And if it is set by a setting in site.conf, it should be overrideable via an UCI call

[rotanid]

And if it is set by a setting in site.conf, out should be overrideable via an UCI call

and i want to repeat the issue with existing nodes...

[kevin-olbrich]

And if it is set by a setting in site.conf, out should be overrideable via an UCI call

and i want to repeat the issue with existing nodes...

I've not checked yet but is the disabled-state update proof? The SSID for example is not.
If it is persistent, it's up to the maintainer of the multi-domain or site profile because we can not determine if it is enabled on purpose or just because the update get's applied during usage-time.

The only option would be to leave it enabled as long as the site or the domain (if MD) does not say otherwise. If the maintainer chooses to disable the button and radio is enabled, it won't enable the plugin. (For Upgrade: We can check if one of the radios is in disabled state und disable the plugin this way).

IMHO some setups require to enforce such a setting. For this case, maybe something like the fastd-peer-configurable flag is usefull?

button-disable = true: Disable button by default (take button-disable-configurable into account)
button-disable = false: Don't touch anything

button-disable-configurable = false: Force state of site.conf / domain and disable button.
button-disable-configurable = true or unset: Detect if radio disabled (leave button enabled) vs. all radios enabled (disable button)

[rotanid]

the disabled state is not update proof, but disabling a button, which may have been used by the node's owner so far, is very invasive, especially if you consider that there is a very big number of node owners which don't know anything about how to change the configuration - if you would even have a way to tell them they can re-enable the button.

btw, we're discussing many details like in other issues without having someone implementing anything.

[kevin-olbrich]

the disabled state is not update proof, but disabling a button, which may have been used by the node's owner so far, is very invasive, especially if you consider that there is a very big number of node owners which don't know anything about how to change the configuration - if you would even have a way to tell them they can re-enable the button.

The whole point about the package is to disable the button. I understand what you mean but those setups would not include the package at all. Only users who think they need an option to disable such functionality would include it and they have a reason for this.

You would not disable the button for all users at once but it is much more likely in areas where other people have access and absolutely no knowledge. Most IT support staff knows these cases: something did not work, someone pressed all buttons, is now even more broken as before.

About the update part: If the disabled state is not persistent in updates, we don't need to check the radio state (and won't be able to).

btw, we're discussing many details like in other issues without having someone implementing anything.

Planning is half the life (Ger.: Planung ist das halbe Leben) - Working on a solution without a plan only leads to recent cases where work is done to implement functionality and it does not get merged, thus frustrating the developer.

I am perfectly okay with implementing this after we agree on a specification that allows it to get merged upstream.

[rotanid]

About the update part: If the disabled state is not persistent in updates, we don't need to check the radio state (and won't be able to).

you are. as i already wrote 2 days ago, i implemented it for our local community-specific fork of this package.

Planning is half the life (Ger.: Planung ist das halbe Leben) - Working on a solution without a plan only leads to recent cases where work is done to implement functionality and it does not get merged, thus frustrating the developer.

as was discussed in another issue today, bikeshedding doesn't help.
if an issue has 100 comments, most won't read the comments and therefore what was discussed has ni impact on a possible implementation (if the commenter is not the implementer)

[kevin-olbrich]

you are. as i already wrote 2 days ago, i implemented it for our local community-specific fork of this package.

Okay but IMHO it would be something that could / should be included in gluon just like geo-loc, autoupdater, domain-switch, etc.?
If everyone has his own implementation to disable a simple button, then it's clearly too much maintenance work in the future. Why not share the maintenance work? Most of gluons users chose it over their own firmware because of this single reason.

as was discussed in another issue today, bikeshedding doesn't help.
if an issue has 100 comments, most won't read the comments and therefore what was discussed has ni impact on a possible implementation (if the commenter is not the implementer)

As I wrote earlier today moring, I might implement this and I already read all other comments. The whole issue is open since 2016. The whole issue was inactive for months until my comment. Don't get me wrong but I try to agree on a specification before I will do any coding. What I get from our discussion is, that I should start coding and ask questions later.
You won't build a house without planning all rooms first. You are also planning features / issues for gluon milestones (if I read right), why? Just because it would be disastrous chaos otherwise.

For OpenStack, blueprints often receive hundreds of comments. Thats part of the job.

Maybe you can share your version of the plugin if it already implements what is needed. It's also your choice if it makes sense to be included upstream.

[rotanid]

i forked here: https://github.com/tecff/gluon-packages/tree/master/tecff-button-bind

[kpanic23]

For years we have some routers with (permanently) disabled WiFi buttons. All you need is a sharp pair of sidecutters...