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‘]‘.
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?)
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.
@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.
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.
Die Parameter inklusive der Gateway-Adressen werden doch in der Kommandozeile übergeben und somit setzt ein Neustart des td-clients die Einstellungen zurück.
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
#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.
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
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…
