port of gluon-ssid-changer for hedy

[akira25]

For Gluon there is a script available which changes the SSID in lack of internet connection. [1] The offline SSID contains a prefix stating the offline status and a portion of the node name. Thus the node should be easily recognisable by its owner. In addition it might prevent the users from getting bad experience with 'broken nodes'.

[1] https://github.com/eulenfunk/packages/tree/master/gluon-ssid-changer

[akira25]

I adjusted the original script for hedy and uploaded it here: https://github.com/Akira25/tmp-ssid-changer/tree/master

I'm not sure how to integrate it proper into the firmware. My intention was to start it e.g. every five minutes via a cronjob. But there might be better ways.

I don't know how to fulfil the conditions of the license. It grants broad permissions but ask to reproduce the copyright notice of the original authors. How to handle that? https://github.com/eulenfunk/packages/blob/master/gluon-ssid-changer/LICENSE

[pmelange]

I took a quick look at the script. A ping test of just one packet can lead to false results. Maybe it would make more sense to do three or more.

Also, I would suggest that the ping test use the -I option. If the node has sharenet==1 and the ffuplink interface has a default route, then test the ffuplink interface. If the node is meshing only, then test the current tnl interface. If the node has neither, then set the ssid to OFFLINE_SSID.

Every 5 minutes seems a long time. Maybe every minute would be better.

In addition to using a cron job, there could be a hotplug script which checks the link status when ffuplink or tnl* go up or down. This would be a bit more dynamic.

When you do the uci commit, I would suggest uci commit wireless

I would add this in firmware-packages/utils or firmware-packages/addons.

[SvenRoederer]

we can probably use pingcheck-package here

[akira25]

I think that is a good idea to avoid several applications from doing multiple pings unecesserily. I made a package from my current code, which is here: https://github.com/Akira25/firmware-packages/tree/ssidchanger/utils/freifunk-berlin-ssidchanger Maybe we can recycle some parts of that.

I tried to implement pmelange suggestion to ping on ffuplink if there is a default route, but had several problems to get that working. Might be found here: https://github.com/Akira25/firmware-packages/blob/ssidchanger_dev/utils/freifunk-berlin-ssidchanger/files/ssid-changer.sh#L32

Have a look here for a working package: https://cloud.pcfw.eu/index.php/s/E24YyLZ34tqyLAK

[pmelange]

@Akira25 I have created a branch called pingcheck (both firmware and firmware-packages). It might be possible to have the ssid changer integrated, but I'm not sure how to handle the case where a node is using only the smart gateway.

But since pingcheck will be taking up and down ffuplink (notunnel) and ffuplink will go up and down on it's own with both tunnel versions, then I really think it is a good idea to do everything in a hotplug script.

[pmelange]

@Akira25 This will get you what the router things is the default route for the dhcp network

ip r get 8.8.8.8 from 10.0.0.1 iif br-dhcp | grep dev | cut -d ' ' -f 5

You could have a hotplug script which checks this interface whenever another interface goes up.

I hope this helps

[akira25]

@pmelange This line works on a mesh-only node. It gets the tnl-Interface correctly. But on a Uplink node (tunneldigger) it gets the address of the tunneldigger-server (172.xxx). Is that supposed to happen?

I tried this code on a mesh-only router:

IFACE=$(ip r get 8.8.8.8 from 10.0.0.1 iif br-dhcp | grep dev | cut -d ' ' -f 5)
# $IFACE contains 'tnl_0a1f280e'
ping -I $IFACE 8.8.8.8

This fails. It also fails with any other Interface I try. But

ping 8.8.8.8

works fine... Clients of the mesh-only-router have access to the internet too. Is this a bug in ping? Which interface do ping test normally?

[pmelange]

OK, It's true that another first step needs to be taken. Here is my recommendation:

(this is pseudocode)

IFACE="x"
ip route show table ffuplink | grep default > /dev/null
if [ $? == "0" ]
  # the ffuplink device is up
  IFACE="ffuplink"
else
  # get the mesh uplink device
  IFACE=$(ip r get 8.8.8.8 from 10.0.0.1 iif br-dhcp | grep dev | cut -d ' ' -f 5)
fi

ping -I $IFACE -q -c 5 8.8.8.8 > /dev/null # use what options make sense here
if[ $? == "0" ]
  # success
else
  # failure
fi

The ffuplink interface should go down on it's own when there is no connectivity over the wan port. This works automatically with tunneldigger and openvpn (after a certain timeout). The pingcheck scripts, when integrated, should take down/up the ffuplink interface when needed.