Clientgrenze 1043v2 an ADSL16 / Flüchtlings-NUK

Dank der Hilfe des Wirtes konnten wir trotz Ablehnung des OB eine Notunterkunft in Herne (Emscherland-Domain) mit ein bisschen Freifunk auf ADSL16-Basis versorgen. Ein 1043v2 steht hinter dem Speedport des Wirts und reicht natürlich nicht um die ganze Halle auszuleuchten, weshalb sich die Clients meistens im Eingangsbereich „klumpen“.

Unser „Mann vor Ort“ hat mich nun gerade angerufen, dass es relativ fix dazu kommt, dass sich keine weiteren Clients einbuchen können - nach 10 bis 15 Clients würden sich Fehlermeldungen der Smartphones häufen und dann würden Leute aus dem WLAN fliegen.

http://map.el.freifunk.ruhr/meshviewer/#!n:c46e1fa11922

Leider gibt es aktuell keinen SSH-Zugang zur Fehlersuche. Trotzdem bin ich sehr verwundert, dass es schon so schnell zu Problemen kommt.

Hat jemand eine Idee, was da falschlaufen könnte? Ist der Uplink zu knapp? Macht vielleicht die Airtime Probleme?

Der Uplink wird in Senderichtung relativ schnell verstopft sein, wodurch Broadcasts zur IP Holung und anfordernder Datenverkehr (gib mir Seite xy) nicht mehr zuverlässig durchgehen. Sobald auf dem Uplink jemand anfängt zu skypen ist ohnehin bei adsl Leitungen zuverlässige Performance nicht mehr gegeben…

Wir habe auf eine 16k Leitung mit 2 x 4300 schon mal 115 User online gehabt. Und surfen ging noch nur Skype kannste schnell vergessen. Wichtig ist die richtige Kanal Wahl. Ein speed port i selben channel ist dann schon mies.

Ich werde mir das mal vor Ort anschauen müssen und gegebenenfalls ein paar Kanäle anpassen. Wird es denn tendenziell besser oder schlechter, wenn wir noch einen zweiten 1043 hinstellen, damit die Leute sich etwas verstreuen können?

Stell doch jeweils nen 841er nach links und rechts, um da alles flächig auszuleuchten.

Aber das ist dann nur Komfort und wird keine Verbesserung der Stabilität ausmachen.

Der Router selber kann es nicht sein, selbst auf 841ern hatten wir beim Nord-Open-Air schon 70 Leute zeitgleich online, ohne das es Probleme gab. Wie man im Meshviewer sieht ist der Ram auch unausgelastet.

Wenn ich mich nicht verrechnet habe macht der Knoten aktuell im Durchschnitt 148 kbit/s in Senderichtung und 2 Mbit/s in Downloadrichtung.

Hier die RAW Werte, gesammelt in 120 Minuten:

traffic: {
tx: {
packets: 1038355,
bytes: 115047850,
dropped: 424
},
mgmt_tx: {
bytes: 18265480,
packets: 116752
},
rx: {
bytes: 1833880652,
packets: 1623553
},
mgmt_rx: {
bytes: 10271916,
packets: 133758
},
forward: {
bytes: 176,
packets: 2
}
},
uptime: 8713.38,

8713 Sekunden / 3600 = 2,4 Stunden

((tx + mgmt_tx) / Sekunden) * 8 = tx bit/s / 1024 = tx kbit/s

(115047850 + 18265480) / 8713) * 8 = 122404 bit/s / 1024 = ~120 kbit/s tx also in Senderichtung

1 Like

Die Antwort würde mich auch interessieren…

Ist evtl. aus Versehen eine Drosselung auf dem 1043er eingestellt worden oder ist evtl. am Hauptrouter des Wirtes etwas anderes priorisiert worden? Das ist natürlich sein gutes Recht, könnte aber eine Fehlerquelle sein.

Ein gleicher Router auf derselben Frequenz wäre natürlich blöd, der müsste verschoben werden.

Der @mattes hat mal die RRD Grafiken aktiviert, damit man den Knoten besser im Auge behalten kann:

http://map.el.freifunk.ruhr/meshviewer/#!n:c46e1fa11922

1 Like

Danke für eure Tipps, ich werde mir das vor Ort anschauen wenn es geht.

Der OB hat erstmal Verwaltungsorder rausgegeben, dass wir keinerlei städtische Infrastruktur nutzen dürfen. Mit etwas Pech lässt man uns nichtmal einen Stecker in die Dose stecken, das wird sich noch rausstellen. Echt blamable Geschichte. :confused:

Ja, ich weiß, wir sind uns in früheren Zeiten öfter mal über den Weg gelaufen

1 Like