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.
root@host2 ~ # ping -I 100.64.9.127 100.64.9.126
PING 100.64.9.126 (100.64.9.126) from 100.64.9.127 : 56(84) bytes of data.
64 bytes from 100.64.9.126: icmp_seq=1 ttl=64 time=11.5 ms
64 bytes from 100.64.9.126: icmp_seq=2 ttl=64 time=11.5 ms
64 bytes from 100.64.9.126: icmp_seq=3 ttl=64 time=20.5 ms
--- 100.64.9.126 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
Bei allen anderen kommt ein Timeout. Via IPv6 lassen sich alle Tunnel anpingen. Ist das ein Problem auf meiner Seite? Und müsste der Internet nicht mit dem einen Tunnel thoretisch auch funktionieren?
.