Modify SSID to "offline.berlin.freifunk.de" if no internet connection about falter-packages HOT 18 CLOSED

Pingcheck is a really cool util, but there are some issues which need to be addressed in order to be able to use it. I will list some of them here...

• pingcheck needs to bind itself to an interface. In most cases ffuplink will be good enough. But if it is mesh-only node, and smartgw is active, then the interface will have to be the tnl_XXXXXXXX interface. Currently there isn't a was to dynamically change pingcheck to bind to a different interface once it is running. I have made an issue a while ago to address this: br101/pingcheck#10
• if the node is set up to not use smartgw, then the default route is stored in the "olsr-default" routing table. The device being used can surely be pulled out of the table, but this can change quite regularly as the mesh dynamically changes. Additionally is the issue in the previous bullet an issue here.
• if the node is set up to not use smartgw and olsrd is configured to put all the routes in the main routing table (instead of the tables olsr, olsr-default, and olsr-tunnel), then it will become even more confusing. Hint: look for a metric of 2.
• binding to wan is a very bad idea for the SSID changer. The problem with using wan is that it is totally valid for a user to "mesh only" but also to install bbbdigger, which per default settings itself binds to wan and will not make a connection otherwise. In this case, the router will send the client traffic via the tnl_XXXXXX interface or whatever is the olsr default route (normally in table olsr-default). Binding to wan in this case would make the router think that it can forward client traffic because wan is up, when the router is really configured not to forward client traffic over the wan port.

from falter-packages.

Pingcheck is a really cool util, but there are some issues which need to be addressed in order to be able to use it. I will list some of them here...

Can't we just always bind to br-dhcp? Since we care only for the internet connection for the clients.

from falter-packages.

Pingcheck is a really cool util, but there are some issues which need to be addressed in order to be able to use it. I will list some of them here...

Can't we just always bind to br-dhcp? Since we care only for the internet connection for the clients.

It's worth testing. Good idea

from falter-packages.

I'd like to mention gluon-ssid-changer. Maybe we can pick some code or some ideas there. I like their scheme of renaming nodes: They change the SSID to contain also a portion of the node name. This is very useful. ^^

from falter-packages.

[EDIT: FOR AN UP-TO-DATE VERSION LOOK INTO THE PR]

from falter-packages.

If someone wants to test I added a feature branch and made a PR: #14

from falter-packages.

Pingcheck is a really cool util, but there are some issues which need to be addressed in order to be able to use it. I will list some of them here...

Can't we just always bind to br-dhcp? Since we care only for the internet connection for the clients.

It's worth testing. Good idea

does not work with br-dhcp :/

from falter-packages.

What about ffuplink?

from falter-packages.

That will only work for uplink nodes and not for nodes which reach the internet through the mesh network

from falter-packages.

That will only work for uplink nodes and not for nodes which reach the internet through the mesh network

Which interfaces do I need to add? Since I check for global connectivity the scripts don't need to know which interface is down.

from falter-packages.

This please take a look at the 4th bullet in #4 (comment)

A router can have internet connectivity and NOT provide an uplink. This is an edge case which should be checked for.

from falter-packages.

Any interface which resides in fw zone freifunk and != ffuplink should be fine isnt it?

But... How can access points, only having ip on a mgmt interface, (acting as a dumb l2 wifi to ethernet bridge), check the connectivity? Altough not entirely correct it should be possible to bind to the mgmt interface, as mgmt internet connectivity somehow correlates to clients having internet connectivity :-)

from falter-packages.

The Freifunk zone also has a special directive option device 'tnl_+' which works as a glob to include any tunnel devices created by the smartgw.

A non-meshing AP would also need to check for internet connectivity. It totally depends on how these dumb AP's are set up. I have dumb AP's which provide access to 3 networks, only only one of them (not freifunk) has a management IP. So, in this case it won't work. I could change all the AP's to have a management address on freifunk, but I preffer not to because I really don't want anyone on the backbone to be able to access these AP's

from falter-packages.

A router can have internet connectivity and NOT provide an uplink. This is an edge case which should be checked for.

I still prefer a solution with only ffuplink and not handling the corner case, before having no ssid changer. I think the corner case is not that usual(?).

from falter-packages.

Unfortunately on the contrary, I think it is quite often. Just look at all the nodes connected to Emma or rhnk.

Only checking ffuplink is, on the other hand, perfect for nodes with no neighbors.

from falter-packages.

Hmmm I would like to test smart gateway, but I have no node or connection to a smart gateway.

from falter-packages.

As this subject had no advancement for some time: What about just using ping -c3 $HOST?

AFAICT that would work interface agnostic. It wouldn't matter, what the current default route is, right?

from falter-packages.

On 7th July we had a short discussion in the meeting on the mechanism. If the script gets called by pingcheck, we just do some ping manually. That way, we can detect an still existing uplink i.e. over mesh. If at least one packet return, we don't rename the wifi and leave it as is.

from falter-packages.