add package gluon-offline-ssid to automatically change the SSID on no Internet connection

[rubo77]

The package is thoroughly tested as an external package in various domains already.

Details see gluon-ssid-changer.rst

source: https://github.com/Freifunk-Nord/gluon-ssid-changer

solves #116

[ambassador86]

Hello @rubo77,
I really like this functionality, one thing that came in my mind when looking through the documentation: Does it work with BATMAN_V? It has no TQ. Instead it will use the speed. I assume turning of the TQ check will also work with BATMAN_V.

[rubo77]

@ambassador86: you are right, I added a hint to the Readme

[CodeFetch]

Thank you for this. It's really annoying being connected to a node that has no gateway connectivity.

Could you make the check of whether a gateway is reachable independent from the package itself?
Now that we support different mesh protocols soon it would be nice if you could trigger an external script e.g. provided by gluon-mesh-batman-adv to test the availability of a gateway connection. You could let your package depend on a meta-package e.g. "gluon-gateway-status" and let gluon-mesh-batman-adv provide the meta-package.
Do you need uci configurable parameters or could you directly read the site.conf instead?

[T-X]

In #1555 (comment) it was decided to check for connectivity via IP addresses provided in the site.conf.

So either add a connection_check_targets to ssid_changer, too, or move the connection_check_targets out of domain_switch and reuse it?

[CodeFetch]

@T-X I'd prefer your second suggestion, as we don't want to introduce redundancy even if it is something as simple as a connection check (which might become more complex over time). I'd suggest to avoid having switch-cases like "if batman else if babel" in packages like the status page, but instead providing own packages for such functionalities which "provide" a specific functionality. That way one does not need to make changes in X packages when e.g. a new meshing protocol comes up. I know that's a bad example, but what I mean is to keep things more modular and interchangeable. Some communities might want to define a connection check only to be successful if there is a specific bandwidth available or if the DNS is also working etc.

[rotanid]

we also use an ssid-changer, but this alone doesnt mean that i think it should be available upstream.
you could for example add a reason why your implementation is better than other implementations.

and i already know which criticism others will have:

• no bash please, use lua or C ( see rewrite in lua instead of shell Freifunk-Nord/gluon-ssid-changer#12 )
• too many options/settings maybe

[rubo77]

We optimized a lot on the code in Kiel so it works stable and is not interfering with the AU for example. It must not be the best solution, but we should add something to the gluon base at least.

Great ideas already, thanks!

We will accept PRs at https://github.com/Freifunk-Nord/gluon-ssid-changer to enhance the code and implement outsourcing of the gateway-check.

I hope we make the best out of it together ;)

[mweinelt]

We will accept PRs at https://github.com/Freifunk-Nord/gluon-ssid-changer to enhance the code and implement outsourcing of the gateway-check.

If you're not willing to work on the pull request this is essentially a dead end for merging it here and I'm not willing to do a review in that case.

[rubo77]

sorry, misunderstanding: I posted the wrong url above. I meant the underlying branch for this PR here:
https://github.com/rubo77/gluon/tree/ssid-changer
You could add a PR to my gluon branch, so it ends up in this PR here. (just thought, sometimes it is easy for someone to add a PR for his thoughts, than explaining which file should go where, and so on...)

And sure. I am highly motivated to work on this.

[rotanid]

ok, that sounds better.
as i already wrote, we won't accept this with bash code, as we have this policy for a while now.
i know that not everyone can code in lua, me neither.

regarding the settings, maybe add a list of every configurable thing in your first comment of this PR together with the default value.
afterwards we can discuss if every setting is really necessary and if the suggested defaults are OK.
i think this package should work with defaults only, too, that's why the defaults should be sane.

[T-X]

Out of curiosity, does anyone have a number regarding how many communities are using an essid changer?

Also, which other ssid changers are out there? Would be interesting to compare. Maybe some have nice ideas that might be worth adopting.

[neocturne]

One big obstacle in the implementation of SSID changers is that they have to modify UCI config at runtime, which we've tried to avoid in Gluon so far. I'm not sure how realistic the addition of dynamic VIF management via ubus to netifd would be (or if I can bring to fruition my long-term plan to remove netifd and UCI from Gluon's network config altogether first).

[rubo77]

This solution doesn't need UCI and there are no disk write actions involved.

@T-X: I think we adopted all SSID changers in the wild and added the features here

[CodeFetch]

Please improve your verbalizations.

[rubo77]

@T-X : In #1555 (comment) it was decided to check for connectivity via IP addresses provided in the site.conf.

maybe we could use this file then and enhance it? https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-scheduled-domain-switch/luasrc/usr/bin/gluon-check-connection

[rubo77]

@rotanid

maybe add a list of every configurable thing in your first comment of this PR together with the default value.
afterwards we can discuss if every setting is really necessary and if the suggested defaults are OK.
i think this package should work with defaults only, too, that's why the defaults should be sane.

The config values and defaults are visible in lib/gluon/upgrade/500-ssid-changer

[mweinelt]

Hi @rubo77

we decided that this changeset is a good candidate for the community repository that is about to be created.

Please stay tuned.

[rubo77]

Rebased to master and added link in docs/index.rst

[mweinelt]

Please retarget this pull request over in the community-packages repository, where this change would be very welcome.

Closing, since the decision in #1649 (comment) is final.

[blocktrron]

Another point to consider here is that reloading the hostapd config leads to radios operating on DFS frequencies to re-perform CAC, which will stop clients from connecting for 60 seconds. I just came across this yesterday when preparing patches for another hostapd issues but this might be a bug in hostapd.

Also this implementation will break with recent OpenWrt due to hostapd not being spawned on a per-PHY base.

[rubo77]

@blocktrron, so you have a solution for this?
Freifunk-Nord/gluon-ssid-changer#26

[blocktrron]

@rubo77 you could patch hostapd to make the scanning process asynchronous.

Even then you might still encounter issues, as the kernel might return an error when rescheduling a running CAC. Solution would be to provide a kernel API for hostapd to query CAC state for a specific channel.

That being said, OpenWrt 20.xx changes how hostapd works (hostapd is now running as a service and only reconfigured by netifd). Current implementations relying on wireless restarts using wifi and config reloads using interrupts will most likely break and need to adapted to use ubus.

See openwrt/openwrt@60fb4c9#diff-a56a9a134db96697b65fa00e73f9e6ae

[rubo77]

This is way above my programming skill

since many communities use the ssid-changer already, we need someone, that knows how to do it and add a patch to get a running ssid-changer on 2020.xx.

help wanted :)

[blocktrron]

I've had to develop a way to dynamically change the SSID braodcasted (no association intended) for a different project. This obviously has multiple shortcomings (e.g. the SSID is never updated in the mac80211 subsys), however this might be a starting point for someone pursuing this SSID changer.

From 4a83ffbd717c8618aa0b170945e6076a8f91dfe5 Mon Sep 17 00:00:00 2001
From: David Bauer <[email protected]>
Date: Mon, 19 Oct 2020 23:25:57 +0200
Subject: [PATCH] hostapd: ubus: add interface to update SSID

Add a method which allows to dynamically alter the SSID broadcasted on
the air.
---
 .../services/hostapd/src/src/ap/ubus.c        | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/package/network/services/hostapd/src/src/ap/ubus.c b/package/network/services/hostapd/src/src/ap/ubus.c
index acc735ca54..ec2099343a 100644
--- a/package/network/services/hostapd/src/src/ap/ubus.c
+++ b/package/network/services/hostapd/src/src/ap/ubus.c
@@ -544,6 +544,35 @@ hostapd_bss_wps_cancel(struct ubus_context *ctx, struct ubus_object *obj,
 }
 #endif /* CONFIG_WPS */
 
+enum {
+	SET_SSID_STR,
+	__SET_SSID_MAX,
+};
+
+static const struct blobmsg_policy set_ssid_policy[__SET_SSID_MAX] = {
+	[SET_SSID_STR] = { "ssid", BLOBMSG_TYPE_STRING },
+};
+
+static int
+hostapd_ubus_set_ssid(struct ubus_context *ctx, struct ubus_object *obj,
+		       struct ubus_request_data *ureq, const char *method,
+		       struct blob_attr *msg)
+{
+	struct hostapd_data *hapd = container_of(obj, struct hostapd_data, ubus.obj);
+	struct blob_attr *tb[__SET_SSID_MAX];
+	char *buf;
+
+	blobmsg_parse(set_ssid_policy, __SET_SSID_MAX, tb, blob_data(msg), blob_len(msg));
+
+	if (!tb[SET_SSID_STR] || blobmsg_data_len(tb[SET_SSID_STR]) > SSID_MAX_LEN)
+		return UBUS_STATUS_INVALID_ARGUMENT;
+
+	buf = blobmsg_data(tb[SET_SSID_STR]);
+	hapd->conf->ssid.ssid_len = os_strlen(buf);
+	os_memcpy(hapd->conf->ssid.ssid, buf, hapd->conf->ssid.ssid_len);
+	return 0;
+}
+
 static int
 hostapd_bss_update_beacon(struct ubus_context *ctx, struct ubus_object *obj,
 			struct ubus_request_data *req, const char *method,
@@ -1311,6 +1340,7 @@ static const struct ubus_method bss_methods[] = {
 	UBUS_METHOD_NOARG("wps_status", hostapd_bss_wps_status),
 	UBUS_METHOD_NOARG("wps_cancel", hostapd_bss_wps_cancel),
 #endif
+	UBUS_METHOD("set_ssid", hostapd_ubus_set_ssid, set_ssid_policy),
 	UBUS_METHOD_NOARG("update_beacon", hostapd_bss_update_beacon),
 	UBUS_METHOD_NOARG("get_features", hostapd_bss_get_features),
 #ifdef NEED_AP_MLME
-- 
2.28.0

[rubo77]

So which gluon version will use the new Openwrt, where the ssid-changer would not work anymore?

[rotanid]

depending on the discussion in #2107 it is next one or the one after that ;-)

[rubo77]

So it seems like the ssid-changer only works up until 2020.2.x and since gluon 2021.1 it is not working any more?

see below. (it still works on v2021.1.2)

[rotanid]

i disagree, there was no change in v2021.1.x that would break it. at least in our fork we didn't do any change in 1.5 years and it still works with the newest release v2021.1.2
though, your statement might depend very hard on which fork is being used, as there are many.

[rubo77]

We use this fork: https://github.com/Freifunk-Nord/gluon-ssid-changer

And I have to elaborate: the ssid-changer still works with the newest release v2021.1.2.

So it will be only on master-builds, where it will not work any more, I guess, and we will need a new solution for the next release then.