Stand der Dinge 2015-05

Ich weiß nicht was da schief zu laufen vermag … ist bei Euch noch ein DNS-Server in der Wolke? Das soll w0 ausspucken:

cat /etc/dhcpd.conf
subnet 10.156.0.0 netmask 255.255.0.0 {
    interface bat-gl;
    range 10.156.252.0 10.156.255.254;
    default-lease-time 600;
    max-lease-time 1200;
    option interface-mtu 1280;
    option domain-name-servers 10.156.3.1;
    option broadcast-address 10.156.255.255;
    option subnet-mask 255.255.0.0;
    option routers 10.156.0.240;
}

wie kann denn der 10.156.0.240 den 10.156.0.241 als GW nennen? Und das auch noch bei dieser Konfiguration auf w1:

subnet 10.156.0.0 netmask 255.255.0.0 {
    interface bat-gl;
    range 10.156.248.0 10.156.251.255;
    default-lease-time 600;
    max-lease-time 1200;
    option interface-mtu 1280;
    option domain-name-servers 10.156.3.1;
    option broadcast-address 10.156.255.255;
    option subnet-mask 255.255.0.0;
    option routers 10.156.0.241;
}

es ist mir auch ein Rätsel. Wenn ich das nicht selbst verwalten würde, könnte ich meinen, dies sei Sabotage. Fastd holt sich jedoch aus überhaupt keiner Datei die öffentlichen Schlüssel sondern checkt den Schlüssel gegen eine Sperrliste. Die Sperrliste ist aber immer noch leer.

Wir haben im Tal auch so einen Knoten, der evil übers VPN angebunden ist. Nun weiß ich woran es liegen könnte.

Wenn möglich den „defekten“ privaten Schlüssel für Später aufschreiben, um es zu reproduzieren, wenn es ein fastd Problem ist.

uci get fastd.mesh_vpn.secret

das ist der Plan für die nächste Firmwareausgabe.

wenn ich mich dunkel richtig erinnere, hatte @DSchmidtberg seinerzeit die 6.0 für Burscheid mit 8.8.8.8 (Begründung: „ist schneller“) gemacht, und das ist nun irgendwie immer noch drin, obwohl ich meine 1043 mittlerweile auf 0.6.3 geupdatet habe.

Theorie (bedarf der Überprüfug heute Abend):
Flashe ich nun einen neuen Router neu über mein Notebook, das mit dem 1043 verbunden ist/war, also 8.8.8.8 im Profil „Freifunk Burscheid“ gespeichert hat (Win speichert ja jedes mal ein neues Profil mit allen Daten, wenn eine neue Netzwerkverbindung nach Deaktivierung erfolgt und nimmt das letzte passende wenn Neuverbindung nach deaktivierten WLAN ) , und gehe danach mit dem neuen Router testweise so online, dass er sich zuerst mit den 10453 verbindet, wird die 8.8.8.8 wieder gegeben.
Wenn ich aber bei einem neuen Router WLAN erst mal ausgeschaltet habe, dann flashe, dann per LAN direkt mit der ISP-Fritzbox verbinde, holt er sich die 8.8.8.8 nicht, auch wenn er danach wieder nur per WLAN mit dem 1043 verbunden ist (wie bei dem mit Leichlingen geflashten gestern) .

Müsste ich mit 2 neuen Routern verifizieren. Vielleicht diese Nacht.

Ich teste die ganze Zeit mit Kabel. Habe auch zwischendurch meinen PC neu aufgesetzt. Es springt immer hin und her. Zwischen Leichlingen und Burscheid besteht kein Unterschied.

Meine Adresse bekomme ich immer von W0 mit entsprechendem GW.

Jetzt Überprüfung der Angaben mit Live-CD

Mir ist nicht bekannt das man in der site.conf nen DNS Server hinterlegen kann. Die sollen doch einzig und allein per DHCP kommen.

Protipp, mit Wireshark mal monitoren was wirklich per DHCP übermittelt wird und von welchen DHCP die Antwort kommt.

Oder mit Linux und der Kommandozeile:

sudo dhcpcd $(ls /sys/class/net/)

Bist du morgen im /dev/tal und hast Lust mit mir die nächste Firmwareausgabe durchzusehen? Dann würde ich mal vorbei kommen. Muss auch nicht so lang werden :wink:

Ich habe bereits geschrieben gehabt, dass wir uns um die Firmware kümmern werden, wenn der Unterbau stimmt. Dafür habe ich 10 Tage eingeplant, die am Montag ablaufen. Du musst also nicht vorbeikommen. Außerdem habe ich noch andere Sachen um die Ohren. Eure Firmware ist vom Februar; im Tal fahren wir noch die vom Januar. Es eilt also noch nichts. Viel früher habe ich auch geschrieben, dass ich mich um die Firmware für Rade kümmern kann, da Ihr nicht die entsprechenden Ressourcen habt.

Bitte wartet wirklich die 10 Tage ab, wie ich geschrieben habe – die Zahl war nicht aus der Luft gegriffen. Und so lange Internet funktioniert, haben das FFRL-Backbone-Team und ich nicht versagt. Am Montag könnt Ihr eure Firmware basteln. Oder jetzt und dann sowieso noch ein mal am Montag …

deaktiviere mal temporär die fastd-Verbindung zum w0 auf dem Knoten:

uci set fastd.mesh_vpn_backbone_peer_wupper0.enabled=0
/etc/init.d/fastd reload

oder was auch immer da für ein Peer stehen mag. Nichts commiten. Dadurch sollte die Route zum w1 besser sein. Entweder ist w0 falsch konfiguriert (Du hast die Konfiguration oben gesehen) oder im GL-Netz stimmt was nicht. Schau Dir die Ausgabe von Wireshark aus, vor allem auf die MAC-Adressen der Quelle achten.

ich stelle in den letzten Tagen immer wieder sporadisch fest, dass die App Threema sich auf meinem iPhone nicht mit dem Server verbinden kann.

Der Verbindungsstatus ist dann nicht rot (keine Verbindung) oder grün (Verbindung besteht), sondern orange.

IP-Adressen der Ziele kenne ich nicht. Das Problem tritt nur ab und zu auf. Wenn es auftritt, bekomme ich mit privatem WLAN sofort eine Verbindung.

Hat jemand eine ähnliche Beobachtung gemacht?

(Sitze in Community Troisdorf, wenn das Problem wieder auftritt, notiere ich meine IP-Adresse.)

Den Beitrag hatte ich nicht mehr vor Augen. Sollte kein drängeln oder scharren in den Startlöchern sein. War eher eine spontane Idee. Das kann gerne noch warten. Für FF Radevormwald habe ich noch genug Punkte auf meiner ZuTunListe :wink:

Ich finde es Toll, dass du so treu deine Fähigkeiten und Begabungen bei Freifunk einbringst und viel deiner Zeit für andere investierst.

Sollte mal etwas nicht so klappen, dann müssen wir alle gemeinsam hinter unserem Projekt stehen und nach Lösungen suchen. - Nicht nach Schuldigen. Deshalb hat niemand versagt. Wir sind alle wertvolle und geliebte Menschenkinder.

1 „Gefällt mir“

@phip

Hier in Troisdorf läuft alles super! Bis auf das Problem von @Reka (das ich hier nicht nachvollziehen kann)

Erstmal DANKE für die Arbeit!

Jetzt fang ich an zu nerven :wink: IPv6?

Hier auch gut,
volle Geschwindigkeit ist wieder erreicht und es gibt keinen packet loss. Der Ping zu einigen meiner Lieblings-Gameservern verbessert sich im Freifunk von 90 auf 50 ms wie auch immer das passiert - ist mir eigentlich auch egal, hauptsache es ist so :smile:
Also auch von hier ein fettes Dankeschön!
IPv6 wäre sehr schön. Ich denke mal nächste Woche Fr können wir die FW umstellen und MTU dazu? Ich hab gehört das brauchen wir für IPv6?

jetzt gerade schon wieder :unamused:

Mein aktuelles DHCP-Lease sagt:
IP: 10.188.240.20
Router: 10.188.0.243

Das ist das Routing Problem. Die Threema-Server sind offensichtlich betroffen. Wenn W1-3 benutzt werden kann keine Verbindung aufgebaut werden.

hab das jetzt mit 2 Notebooks nochmal getestet, eines mit IPv6 disabled, das andere mit IPv6 enabled. Bei bei dem ersten alle Profile in der Registry gelöscht. Dann mit meinem 1043 verbunden, per WLAN.
(Image 1 ist vor Löschen aller Profile auf Notebook 1, Image 2 nach Löschen der Profile + Image 3 ist das 2. Notebook ohne vorheriges Löschen der Profile. Meine Idee war also nicht so falsch, die 8.8.8.8 nimmt Windoof aus dem zuletzt aktuellen Profil.)



Die 8.8.8.8 muss also bei früheren FF-Verbindungen irgendwann mal mit Firmware Burscheid gültig gewesen sein.
Allerdings ist die neu vergebene IP für IPv4 DNS Server bei Notebook 1 irritierend.

Hat immer noch nix mit der fw zu tun

hatte ich auch nicht behauptet, aber die 8.8.8.8. sind ja nicht vom Himmel gefallen, irgendwas muss die ja früher verursacht/vergeben haben.

8.8.8.8 und 8.8.4.4 wurde noch im März für Wupper benutzt, wenn ich diesen Artikel richtig deute:

Wupper hat mehrere Broadcast-Domänen. Das bezog sich auf die BC-Domäne Wupper tal (siehe Prefix 10.3).

Frage:
die drei jüngsten Nodes haben als Link Wupper 2 + 4 und nicht 0 + 1, wie die anderen. Ist das OK?

Ja … 20 Zeichen lang