Gluon Geräte am Mast, Mesh setup zum Uplink

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?

Ja genau. Gluon, 2,4GHz. A ist eine nanostation, B eine nanostation loco.

Richtig.

Richtig.

In den ersten versuchen dekonfiguriert mit ifconfig eth1 down. Später dann als mesh on lan aktiviert.

Dies wird als nächstes versucht. Klingt vielversprechend die eventuell nicht funktionierende Softwareebene durch ein Umswitchen auf Hardwareebene zu beheben.

1 „Gefällt mir“

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.

1 „Gefällt mir“

Ich denke nicht, dafür braucht man richtige Sektorantennen.

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.

Entweder mit einer Picostation. Oder mit einer CPE210, die auf Semi-Rundstrahl umgebaut wurde.
Da löst der lokale Atheros das Problem: Wahlweise (wenn’s reicht im Nahbereich) macht der mit beiden Antennen zwei Streams (MIMO), wenn’s weiter weg ist, dann nimmt er diejenige, die Verbindung, die besser spielt (Fast Diversity)

http://i.imgur.com/OeOaIXo.jpg

2 „Gefällt mir“

Kleines Update:

Ab einem Wert von ca. 25000 wird eine ca. 40% mesh-Verbindung (laut meshviewer) nicht mehr genutzt. Die Gegenstationen tauchen dann auf der Statusseite des Routers gar nicht mehr auf.

Für das in diesem Thread beschriebene Problem hat es jedoch keine Abhilfe gebracht, die schwach gemeshten Verbindungen mit diesem Trick „rauszuwerfen“.

//weitere Tests vorerst unmöglich, da im Ruhrgebiet keine vpn tunnel aufgebaut werden können.

Der Tunnel-Mangel im Ruhrgebiet hat mein Freifunksetup nun komplett offline geschaltet.

Und siehe da: Das wlan mesh hat auf einmal 0 packet loss. Eine vorher mit 30%-60% behaftete Sichtverbindung über 5 m(!) ist nun bei konstant 0% packet loss.

Es muss also nach dem Zuschalten eines uplinks etwas Signifikantes passieren. Entweder werden dann plötzlich unsinnig lange Routen ausgehandelt oder aber es fliegt irgendeine Form von unnützen Paketen durch das Wlan-Mesh, sodass airtime o.ä. verloren geht.

Hat da jemand eine Idee, was eine Quelle für unsinnigen Traffic sein könnte? Berührung zum LAN der Wohnung haben nur 2 uplinks. Die Probleme treten aber schon bei einem Uplink auf. Dieser uplink hat mesh on wan deaktiviert und nutzt das private LAN nur zum Aufbauen des fastd Tunnels. Ich habe daher die Hoffnung, dass es nicht zu einer Interferenz zwischen Freifunk und Privat LAN kommt. Im Umkehrschluss müsste der Fehler im Freifunk-Mesh liegen.

Die Rätsel dieser Installation hier scheinen unergründlich :slight_smile:

//update: Auch die Powerline-Mistlösung scheint keinen Einfluss auf Packetloss zu haben. Selbst bei starker Auslastung der Powerline-Verbindung kommt es zu keinem Packetloss im mesh. Ich warte daher bis wieder Tunnel aufgebaut werden können, um einen eindeutigen Zusammenhang „uplink <> mesh packet loss“ verifizieren zu können.

1 „Gefällt mir“

Natürlich hast du dann nur noch einen Bruchteil des Grundrauschens. Gerade im Ruhrgebiet soll das schon ziemlich heftig sein. Die ganzen Batman-Pakete fliegen durch die DSL-Leitung und werden auch durch die WLAN-Verbindungen gepustet.

Wenn das wegfällt, weil schlicht keine Verbindung zur großen Wolke besteht, entsteht kaum noch Grundrauschen, da ja nur ein paar Geräte in der Nähe hast.

Und dieses Grundrauschen ist geeignet eine 50% WLAN Verbindung so zu stören? Laut router status sollen da immerhin 24 mbits durch passen.

Dabei ist mir der Zusammenhang zwischen packet loss und voller Leitung noch nicht ganz klar. Werden die Pakete wegen voller Leitung verworfen oder zerstören sie sich in der Luft? Eine hohe Latenz ist da übrigens auch bei… 500 MS bis timeout, alles dabei.

Ich weiß es nicht ;). Aber wäre halt so meine erste Idee gewesen.

Dass WLAN schlechter wird, wenn man es benutzt, ist aber schon realistisch.

Fazit des Tages: die Installation ist nun in zwei Inseln aufgeteilt. Dies ist durch das setzen eines hohen mcast Wertes umgesetzt worden. Die beiden Wolken haben nun jeweils 1 uplink.

Bisher recht zuverlässig. Dieser Zustand Jann natürlich nicht die Lösung sein, wenn wir ein mesh Netz anstreben.

Tldr:

  • FF Internet Hotspot geht
  • Mesh ist dazu weitgehend ausgehebelt

Ja, die unendlichen Mengen von fitzelkleinen OGM-Paketen und anderer UDP-Kram (inkl des Dreck von diversen Routerkurzschlüssen) sorgen dafür.
Das ist der prinzipielle Nachteil von Kollisionsdomains mit mehr als 300 Nodes/Clients.
Das mögen hier einige wegdiskutieren wollen mit dem Argument „kein Problem für die Server“: Stimmt!
Für die ist das vielleicht kein Problem. Aber für Clients die DHCP wollen…

Ich habe 11 Beiträge in ein neues Thema verschoben: DHCP-Renewal beim wechsel des Gateways (NAK/concurrent)

Jau das werde ich beim naechsten mal Probieren.
Ausserdem habe ich dann vermutlich auch mehr Zeit habe um das Setup mal zu analysieren.
Hauptsache es gibt da dann auch vorhandene Knoten in Reichweite (Hafenfest/Münster)

CPE210 nur mesh
841 nur client und auf einem anderen Kanal

Eigentlich koennte man hier schon einen zweiten Thread zu starten :wink:

Also ich sag mal DHCP renewal problem war das nicht. Das WLAN Interface am Android Phone war zwischendrin definitiv auch in anderen WLANs und hat dort IPs bekommen.
Es muessen also auch neue DHCP requests gewesen sein.

Ich hab’s mal ausgegliedert. Wobei ich mit dem Betreff noch nicht so richtig glücklich bin.