ich denke ich kann mich Anschliesen da ich am Wochenende auf einem Stadtteilfest in Muenster aehnliche Probleme gesehen habe.
Setup war wie folgt.
Auf der einen Seite der Strasse mit einer CPE210 einen vorhandenen Knoten grob angepeilt ca220m diesen mit Ethernetkabel auf die andere Strassenseite verbunden zu einer 841Kiste. 26m im Rücken der 210er Kiste. Beide mesh auf wan und wlan an.
Obwohl ja zwischen beiden auch ein Kabel war die Verbindung zum 841 nur schlecht. Oft kein DHCP lease bekommen usw.
Entweder die haben sich alle (clients, 841, 210) die airtime geklaut oder die sind nicht mit zwei mesh verbindungen zwischen sich klargekommen oder es gibt schon zuviel Grundrauschen oder einen Bug.
Werde bei naechster Gelegenheit mal versuchen. Das der 841 nur mesh on WAN macht und einen anderen Kanal benutzt.
Ich habe es mir inzwischen angewöhnt, in Locations nur die Fenster/Outdoor-Nodes auf dem offiziellen Kanal zu lassen. Und die Indoor-Geräte mindestens(!) 5 Kanäle wegzuschieben, besser gleich ans obere Bandende.
Der Outdoor-Router und die Meschnodes der NachbarInnen danken es einem.
Kurzfassung:
Sonntag gegen ich würde sagen später Nachmittag ? Da hatte ich eigentlich die ganze Zeit einen Verbindung zum Mesh aber DHCP zu meinem Smartphone wollte einfach nicht.
Längere Antwort:
Das war am Samstag noch nicht der Fall. Der Knoten am Hiltruper Infopoint wollte einfach nicht mit mir ein mesh aufbauen bzw ich habe immer nur ein sehr schlechte Verbindung gesehen, bis mir dann auf der Karte aufgefallen ist das das ein Knoten in der ganz anderen Richtung war. Also erstmal ausgeschaltet. Und am Sonntag morgen die CPE in die andere Richtung gedreht. Zack Verbindung.
Zumindest an der CPE210 hab ich dann Morgens Verbindung bekommen. Spaeter dann auf der anderen Seite der Strasse an der 841 direkt neben mir war es dann so das ich keine IP bekommen habe und schon überlegt habe wie ich denn mal an die Kiste komme OHNE DHCP … ipv6 link local oder sowas hab es dann aber nicht mehr gemacht da mir das auf dem Handy zu nervieg war. Danke LTE und Telekom_Fon Hotspot konnte ich aber auf der Karte sehen das die Verbindung scheinbar aber da war.
Passt exakt. Gab eine Störung auf einem unserer Gateways.
Aus Gründen, die wir noch nicht verstanden haben, wurde nicht automatisch der fallback VPN-Link verwendet. Vermutlich, weil der VPN-Link funktioniert, nur keine neuen IP-Adressen für Clients mehr vergeben wurden.
Damit ist VPN-Fallback erstmal als verbuggt im meinem Kopf gespeichert.
/edit: Rückmeldung aus dem Gluon-IRC, diese Situation wird nicht erfasst.
Klingt nach dem Problem wenn man pro Gateway einen DHCP-Server hat. Und die dhcp-requests (per ebtables) lokal gehalten werden.
Wenn dann ein Router den Gateway wechselt dann versuchen die Clients bei einem renewal-request eine Antwort zu bekommen, die niemals erfolgt. Weil der alte Server nicht erreichbar ist (ist ja am anderen gateway) und der „neue“ sich (per default) nicht autorisiert sieht, negative Antworten zu geben.Und dann ruft der Client sich erstmal gewaltig zu Tode, im schlimmsten Fall bis man einmal den Wlan-Adapter aus- und wieder einschaltet.
Man kann das Problem lösen, indem man den dhcp-servern sagt, auch negative Antworten zu verteilen.
(Das vergrößert aber die Hashtabellen, wenn da viel kommt, DoS zumindest denkbar. Wobei es da „billigere“ Angriffsvektoren gegen unsere Infrastruktur gibt.)
Alternativ baut man zwei batman-netze (mit getrennten fastd-verbidnungen): Einmal Client-Supernodes und einmal Backbone (Supernodes untereinander).
In letztem Backbone filtert man kein DHCP.
Alle DHCP Server bekommen alle Requests und wer als erster antwortet der gewinnt.
Wenn dann ein Router samt Clients das Gateway wechselt, dann bekommt er nach wie vor seine DHCP-Renew/Acks durch, zwar etwas langsamer, aber solange das Netz nicht defekt ist geht es halt.
Ich bin ja nicht so fit, was die Serverdienste angeht.
Aber wo ist der Unterschied, zwischen einem Client, der zwischen Routern roamt, die an verschiedenen Gateways hängen und Routern die das Gateways wechseln?
Warum geht das eine, während das andere Probleme macht?
Das macht bei genauerer Betrachtung leider beides Probleme.
(Sofern man weder den „Freifunk-NRW-Ansatz“ (NAK), noch den „Freifunk-Ruhrgebiet-Ansatz“ (DHCP-Server-Wettrennen) wählt. Wobei das mit dem NAK natürlich hinsichtlich Roaming auch unschön ist. Löst aber natürlich die von einigen hier angesprochenen Probleme bei überlappenden Domains mit identischer SSID.)
Huh? Ich dachte, batman_adv macht aus DHCP-Broad- Unicasts zum selektierten Gateway? In dem Falle düften die anderen GWs auch in der 2. fastd-Wolke die Anfrage nicht mitbekommen. (ebtables nutzen wir in GT auf den GWs nicht.)
On a related topic: kann man nicht einfach DHCP-Relay machen? Ich hatte das schon mal gedanklich mit einem Kollegen durchgespielt und irgendwo lag da ein Hase im Pfeffer, aber aktuell komme ich nicht drauf, wo
Ich habe das noch nicht gedebugt, aber meiner Vermutung liegt da irgendwo ein Hase begraben. Zumindest kenne ich aus mehreren Domains den Effekt, dass Clients regelmäßig beim DHCP-Renewal Probleme haben. Größere als beim ersten Request (der ja nicht per Unicast, sondern per Broadcast geht.)
Gute Idee. Ich sehe da spontan kein Problem, außer dass natürlich mehr Komplexität ins Backbone kommt. Die DHCP-Server sollten ja mindestens zwei im Failover sein, um SPOF zu vermeiden.
In Aachen hatten wir die Sache ursprünglich so verstanden, dass lediglich die Broadcast DHCP anfragen gefiltert werden und die anschließenden Unicast Anfragen zur Verlängerung der lease time direkt durchgelassen werden.
Als er wir die weiteren Tunnel bekommen haben und alle DHCP Server aktiviert haben stellte sich heraus: Das ist leider nicht der Fall.
Nun überlegen wir unsere isc dhcpd im load balancing Betrieb zu nutzen. Das klappt aber soweit ich weiß nur mit zwei und nicht mit vier Servern.
Wie ist denn die Performance beim DHCP Relay, man könnte inzwischen doch stattdessen die dhcpd auch mit einer Datenbank koppeln.
Warum macht man eigentlich kein DHCP auf den Gluon Routern und zentralisiert das stattdessen?
Nur wegen Roaming beim Wechsel des Client zwischen den Routern? Wenn das der einzige Grund ist dann sollte man das zumindest in der Weboberfläche freischalten und könnte so z.B. lokal begrenztes DHCP mit räumlich nebeneinander stehenden Routern machen. Dann bekommt man wenigstens noch eine IP wenn mit den Gateways oder Internet mal was nicht stimmt.
Das ist ein Argument. Alternativ könnte man ja auch eine Statusseite einblenden mit „Offline weil uns das Geld ausgegangen ist. Bitte spenden Sie hier:“
Die Nodes, die nicht am restlichen Netz hängen, sollten Clients keine disfunktionale Default-Route mitgeben. Wer Freifunk nur lokal nutzen möchte, möge IPv6 link-local verwenden. Multicast-DNS zum Auffinden von Diensten funktioniert damit auch.
Und eine Statusseite einzublenden bedeutet, dass wir das Thema „Captive Portal“ wieder ausgraben. Wir haben uns mit vielen Leuten deutlich dagegen ausgesprochen, weil das nicht ohne Eingriff in den Datenverkehr funktioniert; und diesen verbieten wir uns ausdrücklich selber. Siehe Pico-Peering-Agreement.
