Also @freifunksdf kannst du nochmal schildern? Das ist ein Problem das unabhängig von Telekom Hybrid sein wird, deswegen vernachlässigen wir das jetzt mal.
Es wäre nett, wenn ihr ein paar Stichworte gebt, was zu tun ist um das Problem einzukreisen.
Am Anfang hatten wir mal ein DHCP Problem, da bekam man keine IP je nach fastd Server der verbunden war, einfach immer wieder neu verbinden bis ein anderer Server verbunden ist hilft nicht?
Wenn es ein Gateway-problem ist, was ich jetzt vermute:
Gehe mit einem Client mit fixer IP ins Netz, IP-Adresse 10.x.0.55
(x entnimmst Du Deiner Site.conf, .55 ist jetzt mal in die Luft geschossen, in der Hoffnung, dass die frei ist… notfalls nimmst halt 54, 60 oder was auch immer im Bereich 50-100)
Dann setzt Du das Default-Gateway manuell um von 10.x.0.240, auf 10.x.0.241 und hoch bis 10.x.0.249.
Und bei jedem versuchst Du einen Ping zur 8.8.8.8 abzusetzen.
Wenn das „fertig“ ist, schaust Du mal, welche Gatways derzeit angeblich auf der Karte aktiv sind.
Natürlich nur ein Anhaltspunkt, weil auch eine 04:ca:fe:ba.08 nicht zwangsläufig die 10.x.0.248 als defaultgateway per dhcp herausgeben muss und statdessen die 0.240 liefern dürfte.
Meist ist sich aber jeder Server selbst das Gateway.
vermutlich habe ich es hier in den letzten Tagen mit verschiedenen Fehlern zu tun
Zunächst vermutete ich den Fehler in einer kruden Verkabelung eines „Patienten“. Dort lief Freifunk zunächst und dann immer mal wieder nicht.
Dann installierte ich einen FF-Router an besagtem Speedport Hybrid, was zunächst überhaupt nicht funktionierte. Ich laß hier im Forum von Problemen mit dem Gerät und begab mich auf die Fehlersuche ([Wupperstörung seit 2016-04-07 - #6 von FreifunkSDF][1]). Dann ging es irgendwann - hatte offensichtlich nichts mit dem Hybrid zu tun.
Die jetzige Fehlersituation von heute Nachmittag, die wieder nur temporär auftritt/-trat betraf verschiedene FF-WiFi-Mesh-Router an verschiedenen Standorten hier im Dorf. Die Clients erhalten die Information welcher das GW ins Internet ist, erhalten jedoch selbst (sowie der FF-Router) keine IPv4-Adresse (siehe Screenshot) - es bleibt bei 0.0.0.0:
Ich geb mal weitere Hinweise:
Sitze nun an unserem wichtigsten Einwahlknoten am Dorfplatz.
Das Tablet verbindet sich und bekommt offensichtlich die nötigen IP-Adressen mitgeteilt :
musste mir erst einmal ein geeignetes Programm fuer das Tablet installieren…
Das Ergebnis bei mir zu Hause:
Ping auf das 10.186.0.240 funktioniert (auf die anderen .241 bis .246 nicht).
Traceroute auf 8.8.8.8 laeuft problemlos durch.
Am Dorfplatz werde ich es spaeter auch testen und mich wieder melden.
Ansonsten werde ich mal ein paar Router mit KBUU/FW flashen und dann gucken was passiert. Falls es funktionieren wuerde, waere der Hybrid bzw krude Verkabelung als Ursache ausgeschlossen…
Hallo, mal etwas zusammenfassen:
Die Geräte kommen ins Internet, ansonsten würden die nicht in der Map auftauchen und der Ping würde auch nicht funktionieren.
Das Aufrufen von heise.de im Browser liefert einen Fehler. Das lässt darauf schließen, dass es ein Problem mit DNS Auflösung gibt. Probier mal im Browser die Eingabe von 193.99.144.80
Das ist die Adresse von heise.de als IP Nummer, wenn das funktioniert liegt es an der DNS-Auflösung.
Schon mal eine Anmerkung: Bei mir ist der DNS Server = Gateway, evtl ist das die Spur zur Lösung.
Da bei uns die Situation ähnlich der von @Martin ist und meines Wissens nach FFREK an der Domäne Wupper hängt, würden wir den Ausbau aktuell stoppen, bis das Netz wieder stabil läuft. Bzw. könnten wir uns auch vorstellen, eigene Infrastruktur aufzubauen. Doch dazu fehlt uns derzeit das nötige Know-how. Und was muss an Technik bereitgestellt werden? Was kostet sowas?
Bis das geklärt ist, stellt sich uns die Frage:
Wie können wir @phip u.a. (technisch, personell bzw. finanziell) unterstützen?
Die Ansage dazu war doch in den anderen Threads relativ deutlich:
Die vom FFRL bereitgestellten Server für „Wupper“ sind mindestens potentiell überbucht (oder gebrechen aus anderen Gründen an Stablität/Verfügbarkeit, gemessen an PacketLoss&etc).
Die Wuppertaler haben inzwischen privat gespendete Server mit in die Domain genommen, die jedoch lediglich für die Wuppertaler Domain genutzt werden (verständlich).
Andere Communities haben sich aus Wupper zurückgezogen und sind auf eigene Infrastruktur migriert. Oder ergehen sich in Verschwörungstheorien, wie böse die Welt und wie ineffizient der Verein sei.
Darüber hinaus gibt es die ziemlich deutliche Ansage vom FFRL, dass die Vereins-VMs nur noch als Starthilfe (Inkubator) für neue Communities verstanden werden mögen. Dementsprechend wird es allen „etablierten“ nahe gelegt, sich selbstständig zu machen.
Ich persönlich würde mich nicht wundern, wenn die eine oder andere Störungsbeseitigung nicht so schnell passiert, wie es vielleicht möglich wäre, einfach weil damit die „Entwöhnung von der Mutterbrust“ forciert werden soll.
Und um auf die Eingangsfrage zurückzukommen:
Ihr nutzt derzeit VMs des FFRLs, die Wupper für Euch administriert.
Die Frage sollte nicht sein „wie können wir Phip helfen“, denn ich unterstelle schlicht, dass das nicht zielführend ist.
Was ihr machen könntet wäre, bei SoYouStart einen SYS32 zu mieten und den Leuten von Wupper die Zugangsdaten zu geben (zum Kundenportal Eures Accounts, alles andere macht mehr Ärger als das es hilft.)
Oder schlicht die Sache selbst in die Hand zu nehmen.
ich bin nicht immer da … und ich verstehe nicht worum es geht. Ich möchte eine konkrete Fehlerbeschreibung, da ich das, was Ihr hier schreibt, nicht verstehe.
Vorgehensweise bei einer konkreten Fehlerbeschreibung:
Knoten mit nur einem Superknoten verbinden (w0, w1, w6)
uci show fastd
uci set fastd.mesh_vpn_backbone.peer_limit=1
überall uci set fastd.mesh_vpn_backbone_peer_wupper»Nummer«.enabled=0
nur einmal je Superknotentest uci set fastd.mesh_vpn_backbone_peer_wupper»Nummer«.enabled=1
sich uci commit fastd sparen
/etc/init.d/fastd/reload
testen
das Problem Identifizieren und kurz beschreiben Screenshots und Zeug helfen nur Marginal
Sätze wie „in der Stadt läuft alles nur in der Wegstr. nicht“ sagen mir überhaupt nichts … ich lese hier nur „hier läuft alles Prima“ und „hier läuft gar nichts“ – eins von beiden scheint nicht zu stimmen.
ich bin jetzt aber auch meine Checkliste durchgegangen und habe das Problem identifiziert: auf w6 wurde DHCP für Rhein Erft gar nicht konfiguriert. Entschuldigt die dadurch entstandenen Probleme.
