Autoupdater: connect as client if no mesh possible

[rubo77]

If a node without uplink cannot connect to any other node, it should automatically connect to any open wifi to search for updates (and maybe serve more stuff ;) )

[CodeFetch]

What's the current status? I have that on my to-do list, too. I ruminated with Ranlvor that we should add that in the script that checks for updates as some Freifunk communities just don't use an uplink on several nodes. If there is no uplink when the update check script is being executed the router should set up another cronjob that checks the client networks for access to update files with a random starting time to avoid problems with routers that are turned off at night for example. It's no option to check for client networks all the time when there is no uplink.

[rubo77]

This was the result of the brainstorm at ffnordCon:

--vpn--(A)--mesh--(B)

• Knoten als Client im WLAN
• Beim booten einmal nach Updates schauen?
• Trigger für Clientmode Update ab Zeitpunkt X?
• Alle X Zeiteinheiten Clientmode Update probieren?
• Nur wenn der Updateserver nicht erreichbar ist
• Updateserver dann auch per v4 erreichbar?

Variante 1:

• Booten im Normalmodus
• Nach etwa 15min (Mesh muss konvergieren) ein Update probieren
• Wenn Updateserver nicht erreichbar, dann Clientmode

Variante 2:

• Booten im Clientupdatemode
• Updates suchen
• Dann: Normalmodus

Ablauf (stündlich):

• Update manifest laden
• Wenn nicht erreichbar: Zähler inkrementieren
• Bei 1 oder ab bestimmten Wert:
  • Nach offenen WLANs suchen
  • Wenn WLAN gefunden: Clientmode
  • Sonst: auf nächsten Interval warten
• autoupdater sucht erst per v6, dann per v4

---

im client mode auch an WAN und LAN Ports verbindung versuchen?

Idee: Blinkcode auf einer LED (10 mal "Leuchtet die LED gerade?" fragen, "abbrechen" bei falscher Antwort, i.e. den Zähler zurücksetzen und wieder 10 mal fragen)

[CodeFetch]

The problem that I see with these suggestions is that it looks like as though you want to let the node stay in client mode. As I already mentioned we have communities that have nodes which never have a connection to the internet/update servers and are only used to communicate peer to peer via wifi. We don't want them having to build a separate image for this purpose.

Thus my suggestion is to add code to the beginning of the autoupdater script to test whether the updateserver can be reached via the nodes own client or wan interface. If not then set up a cronjob for another script that checks all open wifi networks nearby whether the update server is reachable via one of that networks. If it is, do an update if available. Whether that attempt was successful or not -> remove cronjob that started that script.

With this method the node operates like an ordinary node most of the time.

[tcatm]

@CodeFetch That's actually the plan. "Client mode updates" will be the last resort fallback in case the nodes can not reach the update servers using the mesh and we'd like that to happen for as little time as possible.

[viisauksena]

general question if a gluon-update-fallback module is wanted?

this module would check if batctl gwl -N see some GW, and by that assuming that its batman network could be faulty. This could be due channel change, l2tp<->fastd, fastd_mtu, batv14_v15, changed sn_keys, missed updates for a long time because of being offline etc. and then login as client in his well known ssid and try to do a autoupdate -f

see also discussion here: https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/ see example here : https://github.com/viisauksena/gluon-v14tov15-helper

if this is wanted, i make a cleanup and propose it as pull request

I think one important thing would be to test if the added interface (with maybe other channel) will come up as expected .. or even jist stay down - so the "every hour check" do no harm even when it does not work (on some routers, on 841 v9 and 710v1 it is working at least with the same channel)

[jplitza]

@Adorfer wrote in #656:

As pointed out in the forum 3 days ago: i do not see the point in disturbing "offline clouds" by turning to client mode too fast, too often, since there is potential regression scenarios at least in some radios (where you can't do ibbs, ap and sta at the same time, especially not on other frequencies.)

https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/5

[rubo77]

In Kiel we will use the Mesh Independent AutoUpdater (MIAU) from @TobleMiner to update our domain from Batman 14 to Batman 15:

1. Add this repo to modules:
   https://github.com/TobleMiner/gluon-tsys

2. add autoupdater-proxy in site.mk

The MIAU can update via still existing mesh link without using the batman protocoll. each node is proxying the firmware to serve it via direct mesh-links

[maurerle]

I think this is fixed by using the ffac-autoupdater-wifi-fallback from the community-packages repository: https://github.com/freifunk-gluon/community-packages/tree/master/ffac-autoupdater-wifi-fallback which was merged in https://github.com/freifunk-gluon/community-packages/pull/33

or MIAU or https://github.com/FreifunkHochstift/ffho-packages/tree/master/ffho-autoupdater-wifi-fallback/