es gab keine Fehlermeldung, das war ja das, was mich wunderte. Ansiblie ist sauber durchgelaufen.
Vermutlich war irgendwas anderes Faul. Ich hatte Ansible auf einem Raspberry bei mir daheim laufen. Habs jetzt auf einer VM im Internet laufen gehabt und das scheint geklappt zu haben.
Ich habe jetzt noch ein Problem:
Der 1. Knoten verbindet sich korrekt via L2TP. Geschwinidkeiten sehen soweit auch alle klasse aus.
Wenn sich jetzt aber ein 2. Knoten verbinden will, dann klappt das nicht:
Tue, 12 Dec 2017 14:33:12 INFO New tunnel (id=102 uuid=60e32760257c) created.
Tue, 12 Dec 2017 14:33:12 DEBUG Executing hook 'session.up' via script '/srv/tunneldigger/broker/scripts/addif_domain01.sh ['102', '1', 'l2tp1021', '1446', '80.149.42.151', '37143', '20202', '60e32760257c']'.
Tue, 12 Dec 2017 14:33:12 DEBUG Hook '/srv/tunneldigger/broker/scripts/addif_domain01.sh' script stderr:
Tue, 12 Dec 2017 14:33:12 WARNING Cannot find device "l2tp1021"
interface l2tp1021 does not exist!
Am Knoten liegt, denke ich mal, nicht. Wenn ich den 2. Knoten zuerst einschalte, dann funktioniert dieser. Der Knoten, der sich danach meldet dann aber nicht mehr.
im Syslog wird dazu nichts geloggt.
Ich sehe gerade das das Log mit dieser Meldung geflutet wird: Dec 12 18:00:09 host1 bird: KRT: Received route 0.0.0.0/0 with strange next-hop 51.254.208.1
Sollte damit damit aber nichts zu tun haben, oder?
root@host1 ~ # brctl show
bridge name bridge id STP enabled interfaces
br01 8000.02caffee0102 no l2tp1011
Via ifconfig kann ich nur das erste L2tp-Interface sehen, keine weiteren…
Ich hatte das ehrlich gesagt noch nie, dass ein Tunnel ging, aber ein zweiter nicht. Guck mal ob du ein /sys/log/tunneldigger.log hast. Vielleicht steht da etwas sinnvolles drin.
Thu Aug 3 03:42:11 2017 daemon.debug td-client: Broker usage of vpn3.freifunk-einbeck.de:20001: 85
Thu Aug 3 03:42:11 2017 daemon.info td-client: Selected vpn3.freifunk-einbeck.de:20001 as the best broker.
Thu Aug 3 03:42:12 2017 daemon.info td-client: Tunnel successfully established.
Thu Aug 3 03:42:12 2017 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Thu Aug 3 03:42:12 2017 daemon.notice netifd: Network device 'mesh-vpn' link is up
Thu Aug 3 03:42:12 2017 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity
Thu Aug 3 03:42:12 2017 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Thu Aug 3 03:42:12 2017 daemon.notice netifd: Interface 'mesh_vpn' is now up
Thu Aug 3 03:42:13 2017 kern.info kernel: [ 34.919070] batman_adv: bat0: Adding interface: mesh-vpn
Thu Aug 3 03:42:13 2017 kern.info kernel: [ 34.924664] 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.
Thu Aug 3 03:42:13 2017 kern.info kernel: [ 34.949736] batman_adv: bat0: Interface activated: mesh-vpn
/sys/log/tunneldigger.log gibts leider nicht… Komisch das ganze…
Ich habe es so verstanden, dass es mit dem bugefixten Tunneldigger auch nicht mehr geben wird.
(Finde ich persönlich zwar auch schade, aber ich bin da vermutlich zu altmodisch…)
@Vogelbecker, hast du die Anmeldung einfach mal ein paar mal laufen lassen? Du kannst dir auch Debugausgaben in das Hakenskript schreiben. Also mal die übergebenen Parameter dokumentieren.
Das musst du dann falsch verstanden haben. Es gibt es solange nicht mehr bis jemand es wieder implementiert. Wir haben es immerhin geschafft die Community von wlanslovenija dahingehend etwas zu „öffnen“, dass sie Bugs und PRs jetzt direkt auf Github entgegennehmen und auch aktiv die PRs reviewen.
Insofern ist es jetzt die beste Zeit um so Dinge wie das filebasierte Logging wieder einzuführen.
Dazu muss man sagen, dass Logging im Code ohnehin nicht sehr konsistent ausgeführt ist. Es gibt viele Fehlerzustände, die aktuell gar nicht abgefangen werden und dann einfach zu einem Stacktrace führen. Das könnte man im gleichen Zug auch direkt anpacken.
EDIT: Ich schätze im Übrigen die Wahrscheinlichkeit auf recht hoch ein, dass das mittelfristig wiederkommt. Ich kenne mehr Leute, die es hassen sich mit journalctl oder einer ellenlangen messages rumzuschlagen als solche, die viele kleine, vereinzelte Logfiles hassen.
@Vogelbecker welcher Kernel läuft? Bis Debian Kernel 4.9.0-0.bpo.3-amd64 läuft alles Fluffig bei 4.9.0-0.bpo.4-amd64 geht dann der Tunneldigger nich mehr…
Je nach Kernel-Linie ist der Bugfix unterschiedlich backgeported worden.
Siehe z.B. Meldung aus dem August '17 für 4.10.0-26.
Der Bugfix, der jetzt zu „neuem Tunneldigger-Broker“ + „ungeplantes Router-Firmwarerelease“ führt ist dieser hier.
@MisterCrumble, ich habe keine Ahnung, wie du es geschafft hast, Text zwischen Überschrift und Beitrag reinzukriegen. Aber du kannst gerne die Überschrift auf „mit Ansible“ ergänzen oder so.
Hallo, unter dem ersten Beitrag ist bei mir ein bearbeiten knopf und da habe ich das einfach mal probiert. Mein Thema Vorschlag wäre [Anleitung] [Gluon] Gateway aufsetzen mit Ansible - für Neulinge
Ne Zeit lang lief das recht ordentlich, aber seit ein paar Tagen kommen die Clients nich mehr ins Internet.
IP Adresse wird zugewiesen. Die Clients können das Gateway anpingen, nur ins Internet gehts nicht
Hab schnmal selbst versucht zu debuggen, aber ich komme nicht weiter.
Mir fallen auf den Servern folgende Meldungen im Syslog auf.
Jan 3 13:06:34 host1 bird: KRT: Received route 0.0.0.0/0 with strange next-hop 51.254.208.1
Jan 3 13:06:53 host1 bird: KRT: Received route 0.0.0.0/0 with strange next-hop 51.254.208.1
Jan 3 13:07:14 host1 bird: KRT: Received route 0.0.0.0/0 with strange next-hop 51.254.208.1
51.254.208.1 ist das Gateway vom Serveranbieter
und
Jan 3 12:55:38 host2 bird6: ffrl_dus2: Error: Hold timer expired
Jan 3 12:56:39 host2 bird6: ffrl_fra2: Error: Hold timer expired
Jan 3 12:58:13 host2 bird6: ffrl_fra1: Error: Hold timer expired
Jan 3 12:59:25 host2 bird6: ffrl_ber2: Received: Hold timer expired
Jan 3 13:00:13 host2 bird6: ffrl_dus2: Error: Hold timer expired
Jan 3 13:01:23 host2 bird6: ffrl_fra2: Error: Hold timer expired
Jan 3 13:03:55 host2 bird6: ffrl_fra1: Error: Hold timer expired
Kann das mit den Anbietern zusammenhängen? Host1 ist ne VM bei OVH und host2 ist ein Blech aus der Börse von Hetzner.
Hat für mich nochmal jemand einen Tipp?
das hat nichts miteinander zu tun. Das obere ist bird, der ist für IPV4 zuständig. Das untere bird6, der ist für IP (nach Standard meinte das IPV6) zuständig.
