Tunneldigger client bei gluon 2018.2.1 - fixed

Der td-client selbst läuft sauber durch - resetted seine Broker-Liste halt nicht sauber - overlay patch für gluon will ich noch testen, wenn hier die Standard-Builds für die Rhein-Sieg Firmware durchgelaufen sind auf dem Buildserver.

gluon overlay patch vorbereitet

Keine Software ist perfekt. Es ist absolut üblich dysfunktionale Dienste automatisiert durchzustarten.

lies oben mal genauer - reload und restart bringen in dem Fall nix

Mesh-Verbindung bestand und ssh damit verfügbar.
tunneldigger reload/restart waren wirkungslos.

  • erst Workaround oder patchen des Source sorgen für Umgehung/Entfernen des bad-markers auf dem Gatewayeintrag.

Die Parameter inklusive der Gateway-Adressen werden doch in der Kommandozeile übergeben und somit setzt ein Neustart des td-clients die Einstellungen zurück.

Wo würden die persistent gespeichert?

Ausgabe von ps:

 /usr/bin/tunneldigger -u 525400858269 -i mesh-vpn -t 1 -b domaene14-a.servers.freifunk-muensterland.de:20[abgeschnitten]

ist mit dem patch jetzt gefixt:

broken Broker forciert und dann abgewartet:
Thu Mar 28 01:05:24 2019 daemon.info td-client: Selected fgw02.freifunk-siegburg.de:20003 as the best broker.
Thu Mar 28 01:05:25 2019 daemon.warn td-client: Received error response from broker!
Thu Mar 28 01:05:25 2019 daemon.err td-client: Connection to fgw02.freifunk-siegburg.de lost.
Thu Mar 28 01:05:25 2019 daemon.info td-client: Performing broker selection…
Thu Mar 28 01:05:25 2019 daemon.info td-client: Not trying fgw02.freifunk-siegburg.de:20003 again as it broke last time we tried.
Thu Mar 28 01:05:36 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds.
Thu Mar 28 01:05:41 2019 daemon.err td-client: Resetting status of brokers and starting from scratch.
Thu Mar 28 01:05:41 2019 daemon.info td-client: Performing broker selection…
Thu Mar 28 01:05:42 2019 daemon.debug td-client: Broker usage of fgw02.freifunk-siegburg.de:20003: 1663
Thu Mar 28 01:05:52 2019 daemon.info td-client: Selected fgw02.freifunk-siegburg.de:20003 as the best broker.
Thu Mar 28 01:05:53 2019 daemon.info td-client: Tunnel successfully established.
Thu Mar 28 01:05:53 2019 daemon.notice netifd: Interface ‚mesh_vpn‘ is enabled
Thu Mar 28 01:05:53 2019 daemon.notice netifd: Network device ‚mesh-vpn‘ link is up
Thu Mar 28 01:05:53 2019 daemon.notice netifd: Interface ‚mesh_vpn‘ has link connectivity
Thu Mar 28 01:05:53 2019 daemon.notice netifd: Interface ‚mesh_vpn‘ is setting up now
Thu Mar 28 01:05:54 2019 daemon.notice netifd: Interface ‚mesh_vpn‘ is now up

1 „Gefällt mir“

pull request an freifunk-packages mit dem Patch ist raus.
gluon 2018.2.1 fährt ja aktuell mit:

PKG_NAME:=tunneldigger
PKG_RELEASE:=1

PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=git://github.com/wlanslovenija/tunneldigger.git
PKG_SOURCE_DATE:=2017-12-13
PKG_SOURCE_VERSION:=d7db350011076d6a83855d412885a29a7d142b6e

confirm für pull88 geschrieben. testrouter lasse ich noch für eine Weile online

2 „Gefällt mir“

Super, danke fürs Testen!

Ich würde den PR gerne mergen, kann das aber nicht da ich der Autor bin. Ich habe mal die anderen Maintainer angepingt, vielleicht bringt das was.

Wenn nicht, könnten wir drum herum hacken indem einer von euch den PR submitted, dann kann ich ihn mergen. :wink:

genau das hatte ich gerade vorgeschlagen :smiley:

#pr ist raus - zusätzlich noch ein punkt zum Abschluss des Satzes im syslog und ein syslog err mit starting from scratch Meldung

Hab’s direkt gemacht, bevor ich es wieder vergesse.

1 „Gefällt mir“

#pr 87 tunneldigger patch ist merged, bei gluon packages hat sich nix getan - in der neuen Rhein-Sieg Firmware stable-3.0.5 isser drin und läuft produktiv.

Nachdem der Patch im Tunneldigger repo angekommen ist, habe ich gestern die packages neu geforkt und ein #PR mit der Makefile Änderung rausgeschickt.

1 „Gefällt mir“

ja, aber deine commit message ist nicht OK, bitte orientiere dich an einer alten und ändere deine commit message mit „git commit --amend“, danach kannst du deinen branch force-pushen mit „git push -f“ um die änderung im PR zu haben.

Beispiel:

tunneldigger: update to newest upstream commit:

- bla dinge
- Added cmake related patches to Makefile
1 „Gefällt mir“

hab die Sourcen nur im web vom github bearbeitet - altes repo gelöscht, neu geforkt und dann pr für den Makefile commited - in der webgui vom github hab ich kein stash gefunden, um neu zu committen

noch nie git auf der kommandozeile benutzt - oder die graphischen tools von github?
notfalls schreibst du die neue commit message als kommentar und ich passe es für dich an…

ich hatte den patch vorher schon in den Bau der Rhein-Sieg stable 3.0.5 eingebaut und der buildserver ratterte noch - never touch a running system :smiley: Ich schau mal nach dem Kommentar. Sind beim Makefile ja nur 2 Änderungen mit neuem Hash und Datum.

updated comment

merged

2 „Gefällt mir“

Hinweis: ein merge in dem packages repository wirkt sich nicht automatisch auf Gluon aus.

Dafür braucht es ein Subrelease bei dem die Packages aktualisiert wurden, korrekt?

also eigentlich braucht man gar keine releases, aber die packages müssen aktualisiert werden in gluon

Was aber unterrelasig in der Realität nie passiert. Daher ist de-facto ein neuer Release nötig.