Tunneldigger client bei gluon 2018.2.1 - fixed

#1

Hatte heute bei den Testläufen die erste Auffälligkeit vom tunneldigger client auf der umgestellten Node hinter einem Telekomiker Speedport Router. Mit 2018.2 noch einwandfrei per mesh_vpn eingewählt, hat der Client den Broker als broken eingestuft und wollte nicht mehr verbinden:

Sun Mar 24 14:42:35 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Sun Mar 24 14:42:40 2019 daemon.info td-client: Performing broker selection…
Sun Mar 24 14:42:40 2019 daemon.info td-client: Not trying fgw02.freifunk-siegburg.de:20003 again as it broke last time we tried.

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

Erst als ich alle Server:port -Einträge in /etc/config/tunneldigger auf den einen Gateway umgeschrieben und den tunneldigger restartet habe, kam der Tunnel dann hoch:

Sun, 24 Mar 2019 15:09:30 INFO New tunnel (id=193 uuid=b04e2661a900) created.
Sun, 24 Mar 2019 15:09:30 DEBUG Executing hook ‘session.up’ via script ‘/srv/tunneldigger/broker/scripts/addif_domain03.sh [‘193’, ‘1’, ‘l2tp1931’, ‘1446’, ‘source-IPv4’, ‘41812’, ‘20293’, ‘b04e2661a900’]’.

0 Likes

#2

Was soll einem das jetzt sagen?
Was hast Du umgeschrieben, auf welches Gateway, das Broken Gateway?
Überall aktueller Broker auf den Gateways installiert?
War die Konfiguration auf den Gluon Nodes in irgendeiner Form defekt? (Formatierung?)

0 Likes

#3

alle einträge auf das vermeintlich broken Gateway umgeschrieben - von:

 list address 'fgw01.freifunk-siegburg.de:20003'
    list address 'fgw02.freifunk-siegburg.de:20003'
    list address 'fgw03.freifunk-siegburg.de:20003'
    list address 'fgw04.freifunk-siegburg.de:20003'
    list address 'fgw05.freifunk-siegburg.de:20003'
    list address 'fgw06.freifunk-siegburg.de:20003'

auf:

    list address 'fgw02.freifunk-siegburg.de:20003'
    list address 'fgw02.freifunk-siegburg.de:20003'
    list address 'fgw02.freifunk-siegburg.de:20003'
    list address 'fgw02.freifunk-siegburg.de:20003'
    list address 'fgw02.freifunk-siegburg.de:20003'
    list address 'fgw02.freifunk-siegburg.de:20003'

hoffe, jetzt ist es klarer. Am GW nix geändert. Nur der workaround auf der clientseite.
nur auf fgw02 ist der Dialin scharf - die anderen Einträge sind Reserve.

Config auf der Node war sonst sauber und identisch zu allen anderen Nodes im Testfeld .
Die Auffälligkeit ist auf keinem anderen Router so aufgetaucht.

Vermutung: der client macht keinen reset und versucht es nochmal, sondern belässt es bei der broken Markierung. Am GW gab es keine weiteren Einwahlversuche des Knotens nach dem ersten Abbruch - bis zur Modifikation der Einräge in der tunneldigger-conf auf dem client - danach ging’s sofort.

Betroffene Node

0 Likes

#4

Glückwunsch, du hast https://github.com/wlanslovenija/tunneldigger/issues/87 gefunden :wink:
Evtl. hast du ja Gelegenheit den Fix zu testen und im Pull Request einen review zu machen. Dann kann der fix gemerged werden.

4 Likes

#5

sich einen Keks nimmt :smiley:

2 Likes

#6

@alladin, der Tunneldigger im Gluon hat keinen Wachhund/watchdog dabei, der ihn im Zweifel abschießt. Wir portieren gerade den alten in Ash geschriebenen auf Lua und werden diesen als PR einreichen.

Grüße
Matthias

0 Likes

#7

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

0 Likes

#8

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

0 Likes

#9

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.
0 Likes

#10

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]
0 Likes

#11

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 Like

#12

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 Likes

#13

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:

0 Likes

#14

genau das hatte ich gerade vorgeschlagen :smiley:

0 Likes

#15

#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 Like

#16

#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.

0 Likes

#17

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

1 Like

#18

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 Like

#19

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

0 Likes

#20

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…

0 Likes