Mesh-vpn weg


#1

einer meiner TP-Link Router verbindet sich seit einigen Tagen nicht mehr. Ich hab ihn jetzt zu Hause angeschlossen zusammen mit einem zweiten Zweiten der einwandfrei arbeitet [2a03:2260:115:200:62e3:27ff:fec6:cb20]

Eigentlich müssten die sich doch auch untereinander schon über WLAN verbinden oder?
Ich hab beide im lokalen Netz und bin mit ssh drauf.

Der gestörte hat kein mesh-vpn Device. Was ich beobachte ist, dass er auch keine Namensauflösung macht:

ping www.google.com
ping: bad address ‘www.google.com

ping 2a00:1450:400e:805::2003
PING 2a00:1450:400e:805::2003 (2a00:1450:400e:805::2003): 56 data bytes
64 bytes from 2a00:1450:400e:805::2003: seq=0 ttl=57 time=33.558 m

(ich hab native ipv6 bei mir)

ich finde die Ursache nicht …

was tun?

Dieter.


#2

Hallo Dieter,

wir teilen gerade das Netz in Münster auf. Dabei wird die Domäne 01 auf vier Domänen aufgeteilt (1-4).

Es kann sein, dass wir dabei einen Fehler gemacht haben. Denn nur Knoten aus derselben Firmware meschen miteinander.

An der IP (an der 200 im vierten Block) sehe ich, dass der Knoten schon die Firmware der Domäne 02 bekommen hat. Eventuell war der andere Knoten zum Zeitpunkt des Umzugs offline und hat jetzt „den Anschluss“ verloren.

Außerdem ändert sich durch die Umstellung der benötigte UDP Port von 20001 auf 20002, falls du da etwas gesperrt haben solltest.

Wie heißt der zweite Knoten, der nicht geht? Der DitzAtrops ist online und sollte funktionieren.

Viele Grüße
Matthias


#3

Hallo Matthias,

das isses wohl. Das mit der 200 war mir auch aufgefallen…
Kann ich den anderen Knoten manuell updaten (->link)?
Ich hatte was mit “firstboot” versucht, hat aber nicht viel gebracht.

Bin gerade unterwegs. Wenn ich wieder zu Hause bin schau ich mal nach…

Dieter.


#4

Hallo Dieter,

das setzt das Gerät komplett zurück und löscht alle Einstellungen. Wenn du das wirklich ausgeführt hast, musst du das Gerät vor Ort neu konfigurieren. Ist aber auch nicht schlimm.

Die benötigte Softwareversion kannst du auch manuell einspielen. Bitte such dir über den Firmwaredownloader die passende Software. Also zunächst die Domäne (Münster ist auf 1-5 und 16 im Zentrum verteilt) und dann beim ersten Auswahlmenü auf „Manuelles Update“.

Den Router einschalten, 30 Sek warten -> Resetknopf 10-12 Sekunden drücken, bis alle LEDs einmal aufleuchten -> Gerät startet neu und die Konfigurations-LED (oft ein Zahnrad oder die Power-LED) blinkt im Sekundentakt -> über Kabel (geht nicht per WLAN) PC mit einem der gelben Ports verbinden -> http://192.168.1.1 -> Rechts oben auf erweitert -> Reiter „Firmware“ -> Dort die zuvor heruntergeladene Firmware in den Router laden. Die Konfiguration kann übernommen werden, Häkchen also nicht anwählen.

Die Netzsegmentierung ist nötig, damit das Netz performant bleibt. Leider geht dabei ab und zu was schief. Unser Skript kann z. B. keine Knoten erfassen, die länger offline sind.

Grüße
Matthias


#5

so, zumindest sehen sich jetzt Beide wieder:

2a03:2260:115:200:62e3:27ff:fec6:cb20
2a03:2260:115:200:9ade:d0ff:feab:68fe

Dann kann ich den CasaPazzi wieder vor Ort bringen.

Der 68fe hat immer noch kein mesh-vpn, aber mittlerweile hab ich die Vermutung, dass die sich gegenseitig den Port blockieren, da Beide über ipv4/nat laufen.Eigentlich hab ich ipv6, damit müssten Beide doch parallel zurecht kommen. Aber vermutlich ist das nicht ganz so einfach ipv6 als Uplink zu wählen weil es noch nicht so verbreitet ist.

Zumal habe ich beobachtet, dass einige Router/Provider intern ipv6 vergeben aber extern dann doch nicht können (z.B bei O2). Ich bin da auch noch in der Lernphase. Ein Grund auch, warum ich Freifunk so spannend finde.

Q:
Hätte man den Upgrade auch per ssh machen können?
Ich bin vor 20 Jahren auf der Kommandozeile hängen geblieben und fand jetzt den Zirkus über LuCI etwas nervig :slight_smile: (was aber keine Kritik an LuCI sein soll …)

Gruß, Dieter.

Vielleicht schaffe ich Mittwoch mal wieder vorbei zu schauen.


#6

Definitiv nicht. Das geht problemlos.

Würde gehen, aber der Tunneldigger, unsere VPN-Software, kann leider kein V6. Alle Tunnel werden ausschließlich über V4 aufgebaut. Leider sehr schade, aber bisher hat sich niemand gefunden, der V6 implementieren wollte. Es gab ein GSoC-Projekt (Google Summer of Code) dazu, das hat aber niemand übernommen.

Natürlich. Dazu musst du aber der Installation ein sicheres(!) Passwort setzen oder aber deinen Schlüssel aufspielen. Das geht per LuCI. Und ab dann kannst du dich per IPV6 verbinden, solange der Knoten online ist. Wurde das bei der Installation nicht konfiguriert, kann man später nachträglich nicht per SSH auf den Knoten. Wenn du SSH kannst, würde ich dir das sehr empfehlen. Macht vieles einfacher, am Besten natürlich per SSH-Schlüssel.

Firmware nach /tmp laden und dann sysupgrade gluon…

Auf dem zweiten Knoten tippe ich sehr stark darauf, dass Mesh-VPN nicht an ist, zeig mal

uci show | grep broker | grep enabled

Grüße
Matthias


#7

Manchmal dauert es auch ein wenig länger bis Mesh-Vpn wieder erscheint. Vor allem wenn der nen Meshpartner gefunden hat schien meine Rocket es nicht so eilig gehabt zu haben. Nach einigen Minuten käme dann aber. Der 841er war schon drin und die Rocket wurde kurz zuvor neugestartet. Oder ist das halt sporadisch mal länger je nachdem wie die Router Lust haben?


#8

und tatsächlich:

$ ssh root@192.168.2.29 uci show tunneldigger
tunneldigger.@broker[0]=broker
tunneldigger.@broker[0].enabled='0'
tunneldigger.@broker[0].uuid='98ded0ab68fe'
tunneldigger.@broker[0].address='domaene01-a.servers.freifunk-muensterland.de:20001' 'domaene01-b.servers.freifunk-muensterland.de:20001' 'domaene01-a.servers.freifunk-muensterland.net:20001' 'domaene01-b.servers.freifunk-muensterland.net:20001'
tunneldigger.@broker[0].group='gluon-tunneldigger'
tunneldigger.@broker[0].broker_selection='usage'
tunneldigger.@broker[0].bind_interface='br-wan'
tunneldigger.@broker[0].interface='mesh-vpn'

Nach einem uci set tunneldigger.@broker[0].enabled=1 kommt das mesh-vpn auch wieder hoch:

$ logread
Tue Sep  5 07:25:07 2017 user.notice tunneldiger-watchdog: No neighbours on mesh-vpn interface, restarted tunneldigger.
Tue Sep  5 07:25:07 2017 daemon.info td-client: Performing broker selection...
Tue Sep  5 07:25:07 2017 daemon.debug td-client: Broker usage: 0x46f5d0 domaene02-a.servers.freifunk-muensterland.de 1855
Tue Sep  5 07:25:07 2017 daemon.debug td-client: Broker usage: 0x473d20 domaene02-b.servers.freifunk-muensterland.de 2047
Tue Sep  5 07:25:07 2017 daemon.debug td-client: Broker usage: 0x4740f0 domaene02-b.servers.freifunk-muensterland.net 2047
Tue Sep  5 07:25:07 2017 daemon.debug td-client: Broker usage: 0x473f80 domaene02-a.servers.freifunk-muensterland.net 1855
Tue Sep  5 07:25:07 2017 daemon.info td-client: Selected domaene02-a.servers.freifunk-muensterland.de:20002 as the best broker.
Tue Sep  5 07:25:10 2017 daemon.warn td-client: Received error response from broker!
Tue Sep  5 07:25:13 2017 daemon.warn td-client: Received error response from broker!
Tue Sep  5 07:25:16 2017 daemon.warn td-client: Received error response from broker!
Tue Sep  5 07:25:19 2017 daemon.warn td-client: Received error response from broker!
Tue Sep  5 07:25:22 2017 daemon.info td-client: Tunnel successfully established.
Tue Sep  5 07:25:22 2017 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Tue Sep  5 07:25:22 2017 daemon.notice netifd: Network device 'mesh-vpn' link is up
Tue Sep  5 07:25:22 2017 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity
Tue Sep  5 07:25:22 2017 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Tue Sep  5 07:25:23 2017 kern.info kernel: [  591.710000] batman_adv: bat0: Adding interface: mesh-vpn
Tue Sep  5 07:25:23 2017 kern.info kernel: [  591.720000] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1364) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
Tue Sep  5 07:25:23 2017 kern.info kernel: [  591.740000] batman_adv: bat0: Interface activated: mesh-vpn
Tue Sep  5 07:25:23 2017 kern.info kernel: [  591.760000] batman_adv: bat0: no_rebroadcast: Changing from: disabled to: enabled
Tue Sep  5 07:25:23 2017 daemon.notice netifd: Interface 'mesh_vpn' is now up

Der brooker wurde wohl durch meinen firstboot Versuch disabled. Beim Update hatte ich dann meine Einstellungen beibehalten.

Was ich noch nicht ganz verstehe: ich hab gerade erst (9:40) ein uci commit tunneldigger ausgeführt. In /etc/config/tunneldigger stand bis gerade noch option enabled '0'. Wirken uci set Kommandos sofort und uci commit sichert alles nur über den nächsten Reboot?

Was ich noch beobachtet hatte war, dass die Lock-LED noch aus war. Vielleicht kommt die beim nächsten Boot wieder…

Ich wollte nur ausdrücken dass ich schon von Anfang an ssh nutze und LuCI nur wenn es nicht anders geht (z.B. um den ersten public key installieren :slight_smile: ) Ich halte nichts von Passwörtern und hab bei mir auch überall sshd(8) PasswordAuthentication no gesetzt. Du kannst mir aber gern einen public-key schicken wenn du noch selbst etwas verifizieren möchtest.

Ich schaue heute Abend noch mal was die lock LED sagt. Ansonsten scheint ja jetzt alles wieder zu laufen.
Danke für die Hilfe.

Gruß, Dieter.


#9

Ob die Befehle sofort wirken, ist nicht ganz einheitlich. Manche schon, bei allem was mit Wlan zu tun hat, muss man aber noch

wifi 

ausführen. Commit ist zum Speichern, ohne würde die Änderung nach dem nächsten Neustart verloren gehen, weil es nur im Ram nicht auf dem Flash gespeichert ist.