nach längeren Feldversuchen muss ich feststellen, dass ein ‚ausgelagertes‘ Setup aus nanostation und nanostation loco unzuverlässig läuft. Trotz guter Anbindung (wlan+lan) der mesh only Geräte an einen wdr3600 als uplink ist eine Nutzung von Freifunk an diesen Geräten selten möglich. Wenn überhaupt ist es extrem langsam (<0,1 Mbit/s). Meistens ist schon der Bezug einer IP nicht möglich. (Ruhrgebiet, ff gluon 0.6)
LAN setup:
Wdr3600 uplink ------------10m------------- nanostation ----0,3m---- nanostation loco
Die Verbindung zum uplink ist gegeben durch mittelmäßigen WLAN Empfang sowie zusätzlich mesh on wan per direktem LAN kabel. Im Status dargestellt als 100% Qualität und daher aus meiner Sicht i.O.
Ein am uplink eingeloggtes Gerät läuft wunderbar. Begibt man sich zu den nanostations ist der Empfang zwar super aber die Funktion bricht wie oben beschrieben auf nahe 0 ein.
Per Suche bin ich auf folgenden Gluon bug report aufmerksam geworden:
Dieser beschreibt ein Problem bei der Übermittlung von DHCP auf dem br-wan interface. Kann man einen Bezug herstellen?
Mein Verdacht geht in die Richtung, dass aus irgendeinem Grund extrem schlechte Routen ausgehandelt werden. Das könnte ja zB eine Folge eines Problems auf der LAN-Strecke sein. Rein physikalisch stimmt da aber alles.
Gibt es Beispiele, wo andere eine ähnliche Konfiguration erfolgreich in Betrieb haben?
Wie sind denn die Geräte konfiguriert?
Wenn Clients an den Mastgeräten eine IP bekommen und DNS funktioniert und nur alles sehr langsam ist denke ich eher das sich die Router die Airtime wegnehmen.
Mal Mesh über WLAN überall deaktivieren? Die Loco testweise stromlos machen?
Mit mehreren gluon Routern in einem Raum (wr841) hatte ich damit nie Probleme. Also 5mbit/s waren da immer noch möglich. Hier ist die Datenrate ja völlig zerstört.
Die Vergabe von Routen und IPs funktioniert wie gesagt nicht zuverlässig. Das spiegelt sich auch in ssh-sessions wieder. Nach spätestens 5 Minuten ist eine ssh-session zu den nanostations im timeout.
Das hatte ich mal gemacht. Eindeutige Testergebnisse wurden damals aber nicht erzielt. Werde das nochmal nachholen.
Als die Datenrate mal wieder richtig mies war, habe ich die loco mal abgestöpselt. Das hatte keine positive Wirkung.
Ich werde das Problem dann nun schrittweise debuggen, da wohl Niemand einen ähnlich gelagerten Fall analysiert hat.
Auch wenn das jetzt womöglich hämisch oder ironisch klingen wird, ich meine das jetzt wirklich ernsthaft:
Ich finde das extrem spannend und bin wirklich an den Ergebnissen interessiert. @apo Wenn wir uns mal irgendwo treffen sollten, erinnere mich dran, dass Du ein Freigetränk Deiner Wahl bei mir frei hast. (Früher hätte man ja gesagt „Bier“, aber bevor ich jetzt Mate und wasweisich noch alles aufzähle…)
Solche Probleme kann ich hier nicht sehen. Sowohl bei mir als auch dem Setup was ein Freifunk Kollege im großen Stil macht, siehe Link, gibts mit MESH on WAN keine Probleme.
Es scheint doch eine Abhängigkeit zwischen der nanostation (A) und der nanostation loco (B) zu geben.
Alle Geräte wurden vor den Versuchen zurückgesetzt per „firstboot“. Alle Messungen als Client an A.
Szenarios mit der schwächsten Leistung:
A ist mit B über wireless mesh verbunden. Die Verbindung zum uplink ist ebenfalls wireless mesh. (Qualität 80%)
Datenrate weit unter 1 mbit/s. Sehr instabil. Verbindungsabbrüche.
A ist mit B über wireless mesh verbunden. Zusätzlich gibt es ein LAN-mesh zwischen A und B. Die Verbindung zum uplink ist weiterhin wireless mesh. (Qualität 80%)
Datenrate wie vorher weit unter 1 mbit/s. Weiterhin sehr instabil. Weiterhin Verbindungsabbrüche.
Szenarios mit guter Leistung:
A ist aktiv. B abgeschaltet. Die Verbindung zum uplink ist wireless mesh. (Qualität 80%)
Datenrate über 2 mbit/s. Begrenzug vermutlich durch den uplink-Anschluss bzw. supernodes Ruhrgebiet.
A ist mit B über LAN mesh verbunden. Wireless mesh ist auf B abgeschaltet. Die Verbindung zum uplink ist weiterhin wireless mesh. (Qualität 80%)
Datenrate über 2 mbit/s. Begrenzug vermutlich durch den uplink-Anschluss bzw. supernodes Ruhrgebiet.
Ich schließe daraus folgendes:
Es handelt sich vermutlich nicht nur um eine direkte Störung der Geräte untereinander. Nur bei aktivierter wlan-mesh Funktion auf Gerät nano loco (B) kommt es zu starken Qualitätseinbußen. Dieses wlan-mesh spielt vermutlich ein zusätzlichen hop zwischen A und uplink ein. Da diese zusätzlich noch nah aneinander sind (20cm) könnte dies der Auslöser für die schlechte Leistung sein: packet loss, wenig Airtime, längere Route
Die Strecke „A - B - uplink“ ist langsam bis nicht funktionierend.
Die Strecke „A - uplink“ funktioiniert. B ist hier lediglich Satellit ohne wireless-mesh.
Technisch steht in allen Varianten die direkte Verbindung von nanostation (A) zum uplink zur Verfügung. Diese stabile Verbindung wird aber offensichtlich beim Zuschalten von nano loco (B) nicht genutzt. Es wird dann eine längere und mit extremen packet loss behaftete Route bevorzugt.
Weiterhin scheint die Verbindung mit der Dauer der Nutzung etwas besser zu werden. Dies spricht dafür, dass nach genügend packet loss eventuell doch auf die bessere Strecke ausgewichen wird. Zumindest wäre das eine Erklärung für deutlich schwankende Speedtests, die die Fehleranalyse extrem unangenehm werden lassen.
Die Ergebnisse sind reproduzierbar. Sobald B als wireless mesh Partner „mitspielt“ stellen sich die Probleme ein.
Fun fact: genau dieser Mast hat aber an einem anderen Wohnort ohne Probleme funktioniert. Damals war nanostation (A) der direkte mesh-uplink-partner, da der uplink in Senderichtung stand. Gleiches Setup mit uplink näher zu nano loco (B) verweigert den Dienst.
Falls noch jemand Testvorschläge hat oder Anregungen immer gerne her damit! Als nächstes werde ich den uplink per LAN an die nanostation (A) anbinden.
//Edit: Totales Chaos. Nun werden an Client B keine ipv4 mehr vergeben. Keine Dienste außerhalb des meshes erreichbar. Tests breche ich für heute wetterbedingt ab Der erste Eindruck bestätigt für mich dieses im Bugtracker erwähnte Problem bei mesh on wan. Man wird sehen…
20 cm Abstand zwischen zwei 2,4 Ghz Geräten ist wohl echt zu wenig. Räumlich stärker trennen. Wireless Mesh auf Uplink ausschalten. Bei einer der Nanos Wireless Mesh aus. Bei dieser einen anderen Kanal wählen.
Je nachdem, wie weit du ausleuchten möchtest, vielleicht lieber einen einzigen Rundstrahler wie Bullet oder Picostation.
Über SSH mit ifconfig feststellen wie die Mesh-Radios heißen. Bei den Singlebandgeräten gibt es hier nur eins, bei Geräten mit 2,4 und 5 Ghz zwei. Etwa mesh0 oder mesh_radio0. Dann
uci set wireless.mesh_radio0.disabled=1 && uci commit wireless && wifi
(mesh_radio0 also dementsprechend ersetzen; zweites Radio ebenso)
Wieder anschalten:
uci delete wireless.mesh_radio0.disabled=1 && uci commit wireless && wifi
Ob das Updatefest ist bin ich nicht sicher.
Die Geräte wurden nun voneinander entfernt. Auch mit 3m Abstand bleiben die Probleme bestehen.
Seit mesh on lan mitwirkt ist das gesamte Setup unbrauchbar.
Ein Client nur am uplink funktioniert.
Sobald Nanostation A oder B per lan meshen ist jedoch nach kurzer Zeit Ende für alle Clienten an diesen. Keine Konnektivität.
Ich fange an das Einrichten von mesh on lan als fehlerhaft zu betrachten. Irgendwo scheint es eine Unstimmigkeit zu geben, sodass keine sinnvollen (layer2?) Routen gefunden werden.
Der Bug mit genanntem commit scheint schon sehr nah dran zu sein:
Wie ist den das Setup der Nanostations genau? Welche Typen? Beide Gluon? Beide 2,4 Ghz?
Kabel kommt vom Uplink-Router mit POE und geht in erste NSM? POE Passthrough mit Kabel zur zweiten? Wie ist der Switch/ das Interface der zweiten Lanbuchse an der ersten NSM konfiguriert?
Dies wird als nächstes versucht. Klingt vielversprechend die eventuell nicht funktionierende Softwareebene durch ein Umswitchen auf Hardwareebene zu beheben.
Ob im Datenblatt Richtwirkung steht oder nicht ist egal, auch in die entgegengesetzte Richtung reicht so eine Nanostation locker 30-40 m weit. Daher ist es Quatsch die Nanos so nah beiander zu hängen. Das haben wir dir schon Mal gesagt ;).
Natürlich zerstören die sich die Pakete gegenseitig! Wenn du zwei Marktschreier auf einen Marktplatz stellst und der eine nach Norden und der andere nach Süden brüllt, verstehst du trotzdem nichts.
So weit, so gut; dann stellt sich aber die praktische Frage, wie man denn eine Fußgängerzone o.ä. in beide Richtungen ausleuchtet. Wenn zwei Richtfunken (an der gleichen Fassade) zu Problemen führen, was für Alternativen bleiben? (Sind die Nanostations nicht u.a. genau dafür gemacht, an einem Mast verschiedene Sektoren abzudecken?)
Aber das ist vielleicht ein Thema für einen anderen Thread, denn ich bin mir sehr sicher, dass das nicht der Kern des hier beschriebenen Problems ist, sondern höchstens ein zusätzlicher Faktor.
Das Problem liegt irgendwo im Mesh-über-Kabel-Setup – ich habe (in einem anderen Thread) ähnliche Probleme – und zwar auch mit nur einer CPE.
Ich stimme hier ja auch völlig zu. Selbstverständlich kommt es zu einer nachteiligen Beeinflussung. Wie hoch diese ist ist u.a. eine Größe die ich zu bestimmen versuche.
So sehe ich das auch. Hier ist nicht die Bandbreite sondern die gesamte Funktionalität beeinträchtigt. Zumal es hier im Forum Bilder von 4! CPEs an einem Mast „Rücken an Rücken“ gibt. Das scheint ja auch zu laufen…
Weiterhin wird natürlich völlig offen nach dem Fehler gesucht.
Der erste Eindruck bestätigt für mich dieses im Bugtracker erwähnte Problem bei mesh on wan. Man wird sehen…