ich habe die Meldung erhalten, dass bosselligen.de nicht aus dem FFNW Netz erreichbar ist. Gemeldete Hood Wittmund, tritt aber bei meinem Test auf in Hood Friesland auf. Traceroute (109.237.134.44) knallt bei mir direkt auf die Fresse. Kann das einer mal angucken? Habe leider aktuell keinen PC zur Hand.
Beim Test ist mit auch aufgefallen, dass aus dem Apple AppStore keine Downloads durch gingen. Musste erst ins Private wechseln um ein Tool für traces zu laden.
wget bosselligen.de --bind-address=10.18.136.0
URL transformed to HTTPS due to an HSTS policy
–2021-12-10 14:42:56-- https://bosselligen.de/
Auflösen des Hostnamens bosselligen.de (bosselligen.de)… 109.237.134.44
Verbindungsaufbau zu bosselligen.de (bosselligen.de)|109.237.134.44|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »index.html.1« gespeichert.
In der Oldenburger hood merke ich ebenfalls probleme mit der addressvergabe. Die adressvergabe dauert solangt das mein Handy eine meldung raus gibt das diese netz keine internetverbindung hat. Ich hab es mit einen zweiten handy ebenfalls gebrüft same result. Nach der meldung kommt dann irgendwann ne connected message. vermutlich nachdem die v4 vergeben wurde.
betroffen. zumindest taucht dort überall der String GetAddrInfoReqWrap.onlookup in der /var/log/daemon.log auf. Jetzt ist die Frage, was haben diese Supernode gemeinsam und was unterscheidet sie von denen ohne den Fehler.
zwei Sachen sind mir bis jetzt aufgefallen:
die range bzw. option routers in der /etc/dhcp/dhcpd.pools: eigentlich ist das überall:
range 10.18.foo.2 10.18.foo.254
optiopn routers 10.18.foo.1
nur bei fri01.sn.ffnw.de steht:
grep -E 'r(ange|outers)' /etc/dhcp/dhcpd.pools
range 10.72.40.1 10.72.47.254;
option routers 10.72.40.0;
range 10.18.232.1 10.18.239.254;
option routers 10.18.232.0;
range 10.18.136.1 10.18.143.254;
option routers 10.18.136.0;
also der pool immer von 1 anstatt 2 bis 254 und routers 0 statt 1.
das würde allerdings nur die Probleme in dne domains fri01, fri02 und whv "erklären". Das nächste was mir auffiel, sind die Name der batman-Interface. in den logs auf den betroffenen supernode tauchen folgende auf:
interface bat-lkjadingen;
interface bat-lkermarsch;
interface bat-lkbentheim;
interface bat-lkppenburg;
interface bat-lkenbueren;
interface bat-lkteinfurt;
interface bat-lkjadingen;
interface bat-lkermarsch;
interface bat-lkbentheim;
interface bat-lkppenburg;
interface bat-lkenbueren;
interface bat-lkteinfurt;
interface bat-suedost;
interface bat-lkems01;
interface bat-tossens;
interface bat-lkol01;
interface bat-bre01;
interface bat-default;
interface bat-fri02; <= anders als im log
interface bat-whv01; <= anders als im log
interface bat-fri01; <= anders als im log
interface bat-aurich;
interface bat-leer;
interface bat-stadtos;
interface bat-stadtos2;
interface bat-vec01; <= anders als im log
interface bat-ras01; <= anders als im log
interface bat-loh01; <= anders als im log
interface bat-ol02; <= anders als im log
interface bat-ol01;
interface bat-badiburg;
interface bat-ossued;
interface bat-wtm;
vielleicht kann ja jemand hiermit was anfangen ...
LG & schöne Weihnachten trotz der allgemeinen Lage, hoffe euch und euren liebsten gehts soweit gut
Lorenz
diese ganzen node-Fehlermeldung kamen übgrigens von einer dort noch laufenden hopglassinstanz. habe die mal gestoppt, weil tut ja nicht not, dass die läuft, oder?
ok, vergesst einfach was ich mir da bzgl der Interfacenamen zusammengereimt hatte. das lag alles an irgendwelchen alten hopglass-configs. der hopglass-server wurde nun auf allen supernodes gestoppt und disabled.
habe da einmal mit pssh durch die ganzen /etc/hood.conf durchgegrept. bis auf diese 4 Zeilen ist dort überall *.*.*.1/21 anstatt *.*.*.0/21 eingetragen.
Kannst Note schon ein Fehler gefunden werden? Bei mir stapeln sich Anfragen, geht seit knapp einem Monat nicht wirklich. Habe weiterhin kein funktionierendes IPv4.