Gluon: Auto-change SSID when router has no Internet connection

[rubo77]

To inform the user, that the node has no internet connnection, the SSID could automatically change to "freifunk (offline)" while the router has no net and it is changed back, when the internetconnection is back.

This would solve a lot of struggling for the clients.

[ohrensessel]

is there a way to reliably detect wether the node has a internet connection?
I have my doubts regarding this idea, as freifunk is not just the internet. we always state that internet is only one service among others, so even without the internet freifunk is usable.

[lotarso]

Normally we use something like "city.freifunk.net" as the ssid, right?
The node can check whenever the webpage is not reachable, in this case the node redirects all request for "city.freifunk.net" to a local copy and/or local info page. So we don't need a splash page, but we can provide some information even if the node is offline. I think this is a solution to get us all happy :) ? Also see #115

[rubo77]

Maybe we could also redirect all http-requests of a client that is connected to a node that has no internet-connection to a local page that tells the user that the internet is not reacheable at the moment and why, etc.

[lotarso]

That was my idea too, but @NeoRaider has some good points to not do that. see #115

[rubo77]

you are right:

intercepting the users' HTTP connections

that is what we don't want in any case.

So we could stay with changing the SSID so no user tries to connect and get a bad experience anymore:

_"Ah cool Freifunk! I will check my email .... ;(
Freifunk is crap!!! I will tell everyone, that it doesn't work! "_

Instead there will only be another WiFi _"freifunk-currently-local-only"_ where the user still can connect to all other clients in the local node-mesh.

We could also change the SSID if a limit of connected clients is reached (but that is another issue)

[ohrensessel]

this issue should also be closed when regarding neoraiders comments at #117

if a node temporarily has no internet connection, changing its SSID would kick out the already associated stations. If the internet connection comes back on shortly after this, users might have not even noticed that when the SSID had not been changed.

[tcatm]

This needs a lot more discussion on public freifunk mailinglists (not the Gluon list, this is in no way specific to Gluon).

[RubenKelevra]

We use a concrete implementation for this, parsing and using batctl to check the (selected) gateway connectivity. We use this implementation more than a year, but want to refactor it, before giving it to everyone.

If somebody is interested in the crappy bash-code, take a look at https://github.com/FF-NRW/offline-ssid/

Yes it throws out all clients which are connected currently, but all clients which knows the new ssid, will connect again. Else this gives the ability to select two different wireless-profiles, for both ssids. I think no userfriendly system currently leaves an wifi-connection open, with link-local, if the internet-connection aren't working.

So this gives the user the choice to add an offline-freifunk also to it's known networks.

Else there is an batman-adv issue: When one gateway goes down, batman-adv stick on it, till a timeout of 300 seconds occour. In this time, no new client can use the node, although other gateways work. Now my script detects this, in seconds, and change the ssid. Taking this node from the online-ssid, and gives the client the ability to select another node in range, with online-ssid.

A similar issue occours at boot-time, it takes some seconds to establish the fastd-connection and/or get batman to select an gateway. In this time, no client can successfully connect, so our nodes boot with a 'boot-ssid' and change it to online or offline, after this.

[rubo77]

@RubenKelevra: Great! Any negative side-effects?

[RubenKelevra]

@rubo77 No.

[ohrensessel]

Apart from clients beeing kicked out of the wlan. Or did you solve that?
Am 06.04.2015 3:45 nachm. schrieb "@RubenKelevra" <[email protected]

:

@rubo77 https://github.com/rubo77 No.

—
Reply to this email directly or view it on GitHub
https://github.com/freifunk-gluon/gluon/issues/116#issuecomment-90070285
.

[RubenKelevra]

They are not kicked, the connections are graceful ended. Since the SSID change this behavior is excpected.

Else this is the only thing which makes sense here:
If the clients have the other ssid in there profiles, they can reconnect. Else the clients search for a router which is still "online".

[rubo77]

Sounds great so far, what could be a reason not to implement this?

[ohrensessel]

This behaviour is the exact opposite to how I understand the Freifunk idea.
Internet (and therefore gateway access) is only a service within the
network. Even in a local mesh without any mesh-vpn uplink communication
between clients is possible. Your ssid change makes this infeasible,
reducing Freifunk to gateway access. In Gluon-based firmwares each node
runs a radvd allowing for ipv6 connectivity also in local meshes without
uplink to a gateway.

In addition batman's gateway feature is only used for ipv4. If we therefore
have a ipv6 gateway within the mesh, your ssid change script will probably
not consider this as an internet uplink and change the ssid to offline
until a ipv4 gateway is reachable again.
Am 07.04.2015 10:58 vorm. schrieb "Ruben Barkow" [email protected]:

Sounds great so far, what could be a reason not to implement this?

—
Reply to this email directly or view it on GitHub
https://github.com/freifunk-gluon/gluon/issues/116#issuecomment-90471528
.

[RubenKelevra]

@ohrensessel
Since it does not break any mesh-connections feel free to use the freifunk via ad-hoc network as you want with your devices.

But devices which use the AP expect the wireless usually with an internet-connection and, sadly, with ipv4 enabled. So my script enables the possibility to make a soft change to an offline-freifunk, where you have to define an IPv4 for you device.

Else, your usecase for freifunk is not the usual one. So, the usual user just found a not-working-network if the freifunk-node is on its own. Making the experience for him, using a freifunk-node negative.

The missing feature of routing RA from the gateways, has already been reported as featurerequest for batman, so this feature won't be limited for ipv4 forever.

[rubo77]

I think at least an SSID change would be harmless, if a node is on its own, meaning it has no mesh neighbours at all.

It is essential for our Freifunk reputation to try to give users a positive experience, when they find a Freifunk network and try to connect. So if the information, that a network has no internet (but other local services) would be the best benefit for all.

What exactly is the problem, if the client SSID changes and kicks all users, as long as there are still no other alternative local services anyway?

Maybe there could be an option in the Config Mode to disable this behaviour for your node (and maybe all its neighbours) in case you want to serve a local service on your small offline mesh cloud

[tcatm]

Please note that this issue is closed and my last comment on this still stands: Discuss this elsewhere until you have a clean implementation that we can actually talk about.

[RubenKelevra]

@tcatm well, we use our implementation for 2 years now. It is stable, but we want to do a reimplementation in lua in the long term.

[rubo77]

As an alternative I created an SSID-Notifier at: https://github.com/freifunk-kiel/gluon-ssid-notifier

This will not change the SSID, but add an extra SSID on each offline Node that can serve as a warning, that this node is offline.

I think this is a non-intrusive solution if you want to notify the surrounding

[RubenKelevra]

@rubo77 this is not an solution to the issue that endusers still stuck on a not working network. Nobody wants to check for different networks when the selected one is not working, killing roaming etc. actually this information is also available via status page, so theres no real gain.

[rubo77]

@RubenKelevra I think I have to explain some more: The ssid-notifier doesn't break anything.

The main reason why this issue is rejected, is, that if you change the SSID, like the ssid-changer does, you kick all users, that are connected to that node. This is fine, as long as the client really wants to reach the internet (most clients) but some clients don't care if they get internet connection on the Freifunk net, they just want to transfer data to other clients in the same local mesh cloud.

_We try to build up an infrastructure network, that is independent from the global internet, so changing the SSID when there is no Internet connection is not a desireable solution._

If you want the nodes to sream out loud, that they cannot reach the internet, the only non-intrusive solution is this ssid-notifier, which adds another second SSID to inform the owner like "FF OFFLINE: NodeXYZ" (nobody must use this second WIFI, it is just informative)

I don't suggest to add this to the main gluon repo, but just for clarity I linked it here. This issue may stay closed.

[RubenKelevra]

I don't know any user which uses Freifunk in the described manner but uses no LAN Connection to a Node. So how many percent of the Freifunk uses the Freifunk without expecting an Internetconnection?

[belzebub40k]

@RubenKelevra I agree that Freifunk is mostly used as Hotspot to bypass cease and desist order but the idea behind Freifunk is to create an independent network and internet access is just one service within this network. I don't think we should neglect this idea just because Freifunk is used differently by most people.

[A-Kasper]

I think it should be the decision of the community how a node should behave
if the mainly used internetupling is broken. please implement this feature
and stop telling communities how you want them to configure their network.
this is a highly requested feature request. nobody wants to make it default
but to make it available for those communities who like to use it. for me
gluon is a framework wich should be able to fullfill the communities needs
not the other way round.

i agree that the experience is very important to grow acceptance and to
motivate people to be part of the network. please stop forcing your
communities philosophy to others.

Am 14.09.2016 11:17 schrieb "Ruben Barkow" [email protected]:

@RubenKelevra https://github.com/RubenKelevra I think I have to explain
some more: The _ssid-notifier_ doesn't break anything.

the main reason why this issue was closed, is, that if you change the
SSID, like the _ssid-changer_ does, you kick all users, that are
connected to that node. This is fine, as long as the client really wants to
reach the internet (most clients) but some clients don't care if they get
internet connection on the Freifunk net, they just want to transfer data to
other clients in the same local mesh cloud.

_We try to build up an infrastructure network, that is independent from
the global internet, so changing the SSID when there is no
Internetconnection is not a desireable solution.

If you want the nodes to sream out loud, that they cannot reach the
internet, the only non-intrusive solution is this _ssid-notifier_, which
adds another second SSID to inform the owner. (nobody must use this second
WIFI, it is just informative)

I don't suggest to add this to the main gluon repo, but just for clarity I
linked it here. This issue may stay closed.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/freifunk-gluon/gluon/issues/116#issuecomment-246954059,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIA7UpjF-DY_Ol4pYE2oe4ptwGTdsBpHks5qp7u2gaJpZM4CD6PR
.

[RubenKelevra]

@a-kasper true words.

Feel free to use my gluon-package, currently this requires a small patch of one gluon file.

[rubo77]

We use an enhanced version since 2 years in Kiel and Nord:

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

originaly created for 2016.2.x, there is now a branch for lede (2017.1.x) and 2018.1.x (gluon-master)
The issuetracker there shows the last things to do before we can create a PR for gluon.