Leider noch keine Entwarnung :-( Es wurden mehrere Fehlkonfigurationen gefunden und behoben — aus unerfindlichen Gründen funktioniert aber die Namensauflösung über unser Netz weiterhin nicht.
Ja, richtig, trotz externem DNS-Server kommt keine Namensauflösung zustande. Plan B ist nun ein Neustart des Netzes über andere, neu konfigurierte, Gateways — dies wird aber leider weitere ein bis zwei Tage in Anspruch nehmen :-(
Netzstatus 2018-12-10
Ein Teil der Probleme wurde lokalisiert, an der Lösung wird gearbeitet.
(Details: die virtuellen Verbindungen der Gateways zum DHCP-Server waren nicht mehr funktional (‘links’ alter Kernel, session_id 1, ‘rechts’ neuer Kernel und eindeutige session_id => nix geht durch). Nun werden DHCP-Requests zwar wieder beantwortet — aber diese Antwort kommt nicht beim Client an. Das Gateway als DHCP-Relay bekommt die Antwort und setzt sie auch um, wie im tcpdump zu sehen — aber die Antwort kommt nicht beim Client an, wie man dort per tcpdump sieht )
Hi Kai,
hier wie versprochen etwas Futter für dich. Bin über folgenden Knoten rein gegangen.
33378-freifunk-a42bb0f43a87
Also der DNS sieht bis auf vereinzelte Paketverluste hier etst mal garnicht so schlecht aus.
Hmm, interessant
heute Mittag über Lu-Hollenbeck-1 klappte alles ohne Probleme
Gerade aktuell über 33378-freifunk-a42bb0f43a87 nur DNS aber kein Routing nach Extern
Da warst Du auf dem neuen Gateway gw-test01, welches zu dem Zeitpunkt ggf. auch noch nicht vollkommen fertig aufgesetzt war. Außerdem existieren derzeit noch Querverbindungen (über Test-Knoten mit 1.x-Firmware an Knoten mit 0.7er FW), was auch dazu führt, daß (auch) Dein Knoten noch zwei v6-Prefixe hat:
Das sollte sich im Laufe des Abends dann auch in Wohlgefallen auflösen.
FYI: Die neuen VMs stehen in Hamburg, dementsprechend sehen Traces etwas anders aus:
Ab Ende der Woche hat die Kiste weitere Internet-Zugänge, sodaß wir hoffentlich nicht mehr alles von und nach Berlin karren müssen