[Berlin-wireless] Stoepsel Freifunk Ossastraße

[smilebef at gmail.com]

Am Sat, 15 Mar 2014 09:12:28 +0100
schrieb Sven-Ola Tuecke <sven-ola at gmx.de>:

> Moin Stoepsel, et.al,
> 
> mittlerweile ist der Link ja ganz OK. Allerdings trotzdem nicht
> optimal. Ich habe den starken Verdacht, dass wir uns gegenseitig
> "totschreien". Mithin die Empfangsprobleme hausgemacht sind. Da wird
> auch keine dolle Funkmesskiste von R+S helfen fürchte ich. Sondern
> nur ein bisserl Nachdenken. Ich schreib' mal ein paar Stichpunkte auf:
> 
> - Die Emmaus (und die Zwingli) sind bei Kanal 13 / 2.4 Ghz relativ
> taub. Das sieht man an den asymmetrischen ETX-Werten. Ich bemerke es
> z.B. auch selbst, weil ich seit Jahren an Bockis Kiste in Richtung
> Süden hänge: die 104.130.77.80 ist auf dem Hochhaus gegenüber MTV am
> Osthafen und guckt auf meinen Balkon. In Empfangsrichtung zu mir
> alles wie gewohnt - ich wohn' ja sozusagen im Windschatten - aber die
> Senderichtung (zu Bocki) ist deutlich mieser geworden.
> 
> - Ich hatte Anha in der Leitung (der wohnt in Köpenick irgendwo am
> Müggelsee). Der beschwerte sich, das "die Emmaus und die Zwingli seh'
> ich recht gut, aber ich kann nix senden". Das sind 14 Kilometer. Und
> er hatte wohl wie gewohnt auf 2.4 Ghz mit einem WRT-mit-Uralt-Firmware
> probiert. 14 Kilometer ist die halbe Stadt. So viel Sendereichweite
> auf 2.4 ist unnütz. Er hat mittlerweile eine 5 Ghz-NanoStation in
> Betrieb und das geht um Klassen besser, auch wenn da noch
> Optimierungspotential vorhanden ist.
> 
> -  Ich hab' dann auf der Zwingli und der Emmaus die MCast-Rate
> deutlich nach oben geschraubt. Zur Erläuterung: die Chips / Treiber
> verwalten eine variable Datenrate für Unicast (Basic-Rateset). Die
> wird je nach Radiosituation hoch- und 'runtergeregelt. Unicast ist
> dann, wenn die MAC-Adresse des Kommunikationspartners bekannt ist und
> ein Datenpaket mit einer Ziel-MAC-Adresse ungleich FF:FF:FF:FF:FF:FF
> gesendet werden soll. Das sind Datenpakete (Normaldaten,
> 802.11n-QDaten, ACK-Antwortpakete und Probe-Answers). Und dann gibt
> es da noch die Multicast-Rate. Die kommt zur Anwendung, wenn ein
> Rundrufpaket gesendet werden soll. Also mit Ziel-MAC-Adresse
> FF:FF:FF:FF:FF:FF ohne ACK-Antwort. Das sind ARP-Whohas?, IPv6-NDP,
> OLSR-Pakete, Batman-ADV-OGMs, Beacons, Proberequests, RTS, CTS usw.
> Die Multicast-Rate ist fest eingestellt. Und häufig erstmal auf den
> niedrigsten Wert: 1 MBit bei 802.11b/g. Und wir senden ja jetzt nicht
> nur OLSR-Rundrufe sondern das Batman-ADV erzeugt ja auch noch welche.
> Quantitative Untersuchung hab' ich jetzt aber noch nicht gemacht.
> 
> - Das Senden eines (längeren) 1 MBit-Paket dauert ewig. Und belegt in
> der Zeit die Luft. Ich hatte damals aus dem Grund in der
> Uralt-Firmware mal die Multicast-Datenrate auf 5.5 MBit
> voreingestellt. 5.5 ist B-Mode. 5.5 und 11 MBit im B-Mode waren
> zumindest mit den alten WRTs wesentlich zuverlässiger /
> weiterreichend als z.B. 6 MBit im G-Mode. Das ist alle Jahre her,
> aber die aktuelle PBerg-Firmware nutzt immer noch diese 5.5-Vorgabe:
> "uci show wireless|grep rate" zeigt es an. Übrigens konnte man zwar
> bei den alten Geräten die Multicast-Rate einstellen, bestimmte Pakete
> (Beacons, RTS/CTS, Probeanswer) wurden aber trotzdem mit 1 MBit
> gesendet. Aus dem Grund ist es zumindest bei den alten WRTs auch
> ratsam, die Beacon-Häufigkeit (10 mal die Sekunde) 'runterzudrehen.
> 
> - Und es gab damals einen Software-Schalter für "sende keine
> Probe-Answer". Hintergrund ist der, dass in der Stadt / auf einer
> Veranstaltung relativ viele Mobiltelefone / Laptops usw. mit aktiven
> WLAN unterwegs sind, die alle auf automatisches Verbinden bei
> Verfügbarkeit eines bekannten WLANs eingestellt sind. Die tun das mit
> "Active Scanning". Senden also Probe-Requests. Und unsere AdHoc-Radios
> antworten alle mit Probe-Answer. Wenn 8 AdHoc-Radios in der Nähe sind
> also sozusagen 8-mal verstärkt. Alles auf 1 MBit - die Luftzeit wird
> dann aber einer gewissen Gerätezahl komplett mit Probes / Answers
> verbraucht.
> 
> - Kommen wir mal zu aktuellen Geräten / Firmwares / Treibern. Bei den
> Ubiquity-M2 mit Ath9k ist die Situation etwas anders. Man kann
> ebenfalls eine Multicast-Rate einstellen. Und zwei (soweit mir
> bekannt ist voneinander unabhängigen) Sets aus möglichen
> Unicast-Senderaten: "legacy-2.4" und "mcs-2.4" (siehe "iw | grep
> rate"). Legacy meint "802.11b/g" und MCS meint "802.11g/n". Die
> Multicast-Rate stellt bei den Ath9k-Geräten offenbar 802.11b/g für
> Broadcasts ein, ein Erzwingen von 802.11g/n für Broadcasts geht
> offenbar nicht. Mit der Multicast-Rate kann man also nicht "ignoriere
> alte B- und G- Radios komplett und mach' nur noch N" einstellen. 
> 
> - Jedenfalls beeinflusst die Multicast-Rate bei Ath9k auch die
> Senderate für Beacons und Probe-Answers. Das ist anders als früher.
> Wobei RTS/CTS immer noch auf 1 MBit gesendet werden, aber die höhere
> Datenrate bei Beacons ist ja schonmal ein Fortschritt. Ich hab' dann
> auf der Emmaus einfach mal Multicast=36 Mbit eingestellt. Und z.B.
> nachgeschaut, ob der Link zur 104.196.0.112 (Stoepsel2 in der
> Ossastraße) symmetrischer wird. Tut er auch: LQ (Emma-Empfang) wird
> um einiges besser und NLQ (Emma-Senden) wird nicht viel schlechter.
> Mit der Theorie hab' ich mich dann mit meinem Mobiltelefon auf den
> Hügel am Ende des Görlitzer Parks gestellt, das sind ca. 1 Km und
> Kirche gut im Blickfeld. Es geht doch nix über "Ausprobieren" ;-)
> Jedenfalls musste ich die Multicast-Rate für den Access-Point-VAP
> dann wieder 'runterdrehen (auf 6 MBit), damit ich einigermaßen
> akzeptable Download-Werte auf meinem Mobiltelefon erhalte (ca. 300
> KByte/sek).
> 
> Die nächsten Schritte wären: Einstellen und ausprobieren, ob die
> Unicast-Datenrate wirklich nicht mehr in den B-Mode abfallen kann: 1,
> 2, 5.5, 11 MBit/s sollten auch unter übelsten Radio-Bedingungen nicht
> benutzt werden. B-Mode ist nicht mehr. Am liebsten wäre es mir wir im
> A-Mode: die niedrigste Rate ist 6 MBit. Wenn ein Gerät da keine
> Verbindung herstellt: Pech. Mir fehlt auch der Schalter: "keine
> Antwort auf Probe-Answer". Und der Schalter:
> Weg-mit-der-B-Mode-Protection (das ist: wenn ein G-Mode-Paket
> gesendet werden soll, wird für evt. vorhandene B-Mode-Geräte ein
> RTS/CTS gesendet "haltet mal die Klappe". Kostet alles zusätzliche
> Luftzeit wegen 1 MBit.
> 
> Dann wäre da noch die Sendefeldstärke. Die soll noch *runter*. Bis
> Nachbarn mit einigermaßen akzeptabler Antenne in etwa zur Emmaus
> symmetrische ETX-Werte anzeigen. 36-MBit-Broadcasts ist vielleicht
> etwas radikal, ich tendiere eher zu 24-MBit -> sind Erfahrungswerte
> und nicht in Stein gemeisselt. Möglich, dass so Kaninchendraht über
> den Fenstergittern der Emmaus eine bessere Entkoppelung der
> 2.4-Nanostations macht. Offenbar funkt es durch die vorhandenen
> Gitter mit Maschenweite ~ 3cm durch, bin aber nicht ganz sicher denn
> das ist Nahfeld und da geht "um die Ecke". Und dann gibt's da immer
> noch das Konzept, was Bastian und Elektra derzeit auf der Zwingli
> fahren: jedes Node-chen sein Kanäl-chen. Also mehr von dem allgemein
> vorhandenen Frequenzkuchen zu benutzen. Aber das wäre für mich
> jedenfalls erst der letzte Optimierungsschritt.
> 
> Ach und als Tipp: das Horst-Monitoring-Tool funzt auch mit Ath9k,
> bequemes Startscript siehe
> http://wiki.freifunk.net/Berlin:Standorte:Emmauskirche.
> 
> Gruß // Sven-Ola
> 
> Am 14.03.2014 10:40, schrieb Christian Heise:
> > wobei mir der Link zur Emma immer noch zu schlecht ist. Seit dem
> > Upgrade auf der Emma habe ich immer noch sehr üble ETX Werte, obwohl
> > ich heute die Antenne neu ausgerichtet habe. Zur Not muss ich mir
> > mal den Rode & Schwarz FSH3 von Arbeit mitnehmen und die Pegel
> > prüfen und evtl. nochmal genau einmessen. 
> 
> 

Ich fände ein wenig Monitoring nicht schlecht.
Ich habe mir auch schon überlegt, mal Richtungsabhängig zu Messen. 
Aber vielleicht kann man mit Horst auch ausreichend die Quellen
differenzieren. 

Ist es möglich, dass irgend welche falschen Einstellungen auf
benachbarten Stationen den gesamten Verkehr lahm legen?
Zum Beispiel, wenn benachbarte Stationen mit unterschiedlichen Modi gbn
fahren und dann vielleicht noch 20 und 40 MHz gemischt werden?
Eine neuerliche Besonderheit ist ja auch die vergrößerte
Erreichbarkeit. Jetzt mit den ganzen Kreuz-Schnickschnack kommen die
Omni-Antennen hinzu. Damit werden auch diverse Kreise zwischen Emma
und Zwingli geschlossen.

Ich vermute mal, dass die in der Netzkarte die Linien-Farbe die
Verbindungsqualität darstellt. Dort sind eine ganze Menge rote Linien.
Rund um Emma und Zwingli. Gerade bei der Emma sind ziemlich viele rote
Linien. Da könnte was verbastelt sein.

Übrigens wird bei mir die große Routingliste geladen, aber
meine IP-Adresse taucht auf der Zwingli nicht auf.

Von uns aus macht es den Eindruck, dass die gesamte Zeit
es nicht möglich ist Kontakt mit der Zwingli aufzunehmen. 
Ich kriege zwar die Routingtabelle. aber ich sehe die Zwingli nicht im
viz-Tool.
Nur hin und wieder kommt überraschend eine Sekunde lang Super Empfang.



-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 230 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140316/1ef272b1/attachment.pgp>