[Wien] schlechter Empfang

Sa Mai 19 14:11:10 CEST 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Also, hab' jetzt auf dem alten (gut der ist noch nicht ein Jahr alt)
Linksys jetzt eine Backfire drauf.

http://wan02.mi001.wien.funkfeuer.at/

aus dem
ftp://oe1xrw.ozw.wien.funkfeuer.at/Trunk/brcm2.4/r1133-2012-02-20/brcm-2.4/
ob das mit dem Trunk gut war weiß ich noch nicht, bis jetzt
funktioniert alles.

Zwei kleine Anmerkungen habe ich:

1) Warum kann man beim Wireless nicht den Kanal auswählen? Den habe
ich per Hand in die /etc/config/wireless eintragen müssen?

2) Im Menü Freifunk (Grundeinstellungen und Kontakt) vergisst der gute
Kerl (Router) alle Einträge nach einen Kaltstart.

Gut das kann halt alles an der Trunkversion liegen und das Risiko
einer fehlerhaften Software liegt bei mir.

Wenn es noch Optimierungspotenziale gibt? Bitte ich um Eure Unterstützung.

so jetzt gehe ich radln bei dem schönen Wetter

PS: Zur Info, falls ihr es nicht eh schon wisst. Funkfeuer ist mit
Gratiswlan am Life Ball 2012.

Sonnige Grüße

Christian

Markus Kittenberger schrieb:
> 2012/5/18 Christian Bruckner <(spam-protected) 
> <mailto:(spam-protected)>>
> 
> Ich werde die SW durch eine aktuelle  tauschen. mal seh'n was sich
>  ändert
> 
> da es mit 741.v4 mit einer 1,5wochen alter genauso funktionierte, 
> vmtl. wenig
> 
> 
> Mit sonnigen Grüßen Christian Bruckner +43 680 3255220 
> <tel:%2B43%20680%203255220>
> 
> Ebendorferstraße 19 A 2130 Mistelbach
> 
> Von meinem Mobilephone gesendet
> 
> Am 18.05.2012 um 09:17 schrieb Markus Kittenberger 
> <(spam-protected) <mailto:(spam-protected)>>:
> 
>> ist zwar schon ne Weile her aber btw
>> 
>> hab grad tplink 741.v4 mit openwrt trunk vs linksys (mit 
>> freifunkfirmware) getestet,.. (klar ist kein 1043)
>> 
>> sowohl AP/client als auch adhoc hatte ich vernünftigen durchsatz
>> 
>> adhoc symmetrische 18-19 mbit, ap/client 23/19mbit
>> 
>> und das egal was für ne multicastrate am linksys eingestellt, 
>> oder ob g oder n hwmode am tplink, oder bg oder g-only mode am 
>> linksys.
>> 
>> lg Markus
>> 
>> 2012/5/13 Erich N. Pekarek <(spam-protected) 
>> <mailto:(spam-protected)>>
>> 
>> Hallo akku!
>> 
>> Am 2012-05-13 16:18, schrieb gerhard poller:
>> 
>> seh grad alter linksys versus neuer TP-Link TL-WR1043N/ND
>> 
>> Das habe ich auch gesehen ;-)
>> 
>> 
>> linksys sendet viel schlechter vor allem bei höherer 
>> sendeleistung oft (nicht immer)  hilft da radikale reduzierung 
>> oder neue hartware ;)
>> 
>> 
>> Freilich hast Du mit der Reduktion der Datenrate recht, vor 
>> allem, wenn wir mit DSSS/BPSK statt mit QAM modulieren - das 
>> scheint hier der Fall zu sein:
>> 
>> Belässt man den Linksys auf den Einstellungen laut Wiki, v.a. 
>> Multicast-Rate 5.5, bricht beim TP-Link im selben Raum oder im 
>> Nebenzimmer die LQ zusammen. Auch die NLQ ist signifikant unter 
>> 1.0. Verbunden waren beide mit Geräte mit einer nominalen Rate 
>> von 5.5Mbit RX und TX.
>> 
>> Schaltet man am Linksys die Datenrate und Multicast auf 
>> Automatik, verbinden sie sich nur noch mit 1 Mbit. Auf LQ/NLQ 
>> habe ich nicht geachtet.
>> 
>> Schaltet man nun die Multicast-Rate am Linksys auf 11 Mbit, hat 
>> man der jeweiligen Verbindungsqualität auf einmal angemessene 
>> Datenraten zwischen 11 und 36 Mbit. (Nebenraum) und eine LQ/NLQ 
>> von 1.000.
>> 
>> Bei der BFV werden an sich weder Multicast-Raten noch Basisraten 
>> noch fixe Datenraten eingestellt; LuCI bietet in Joe's Builds 
>> keine Einstellmöglichkeit dafür - Ausnahme: madwifi. In 
>> /etc/config/wireless kann man per "option mcast_rate '11000'" im 
>> Abschnitt für das Ad-Hoc-Netz diese Einstellung händisch 
>> vornehmen.  Ob das vor allem mit ath5/9k auch funktioniert, habe 
>> ich noch nicht getestet. Einige Tests auf dem 1043 mit rate, 
>> minrate, maxrate und basic_rate sowie mit "iw wlan0 set bitrates 
>> legacy-2.4 12 18 24", laut 
>> http://linuxwireless.org/en/__users/Documentation/iw#__Modifying_transmit_bitrates
>>
>>
>> 
<http://linuxwireless.org/en/users/Documentation/iw#Modifying_transmit_bitrates>,
>> zeigten keine zuverlässige Wirkung. Auch G-Only-Mode (auf
>> beiden) brachte nicht das gewünschte Ergebnis.
>> 
>> Da Multicast-Raten jenseits der 11Mbit laut einigen Quellen 
>> (OpenWRT-Forum, Wikipedia) für den Ad-Hoc-Mode nicht
>> spezifiziert sind, scheint es, dass eine der beiden oder beide
>> Firmwares den Default von 1.0 Mbit wählen, womit wir dann trotz
>> neuerer Hardware mit dem im Wellenspektrum "unsaubereren" DSSS
>> modulieren (siehe auch
>> http://bridgingthelayers.org/__channel_overlap.html 
>> <http://bridgingthelayers.org/channel_overlap.html> für Effekte 
>> auf kurze Distanz). Siehe Laut OpenWRT-Forum (Meldung ca. 2
>> Jahre alt) können im HT (High Troughput)-Mode bei Openwrt keine
>> Raten fix eingestellt werden. Ich schließe aus diesen
>> Informationen und den Versuchen an Christians Routern, dass trotz
>> guter Verbindung die beiden Stationen sich dann nach der
>> niedrigst-möglichen ausgehandelten Multicast-Rate verbinden.
>> 
>> 
>> hf akku
>> 
>> seh grad einer neue firmware der andere alte freifunk
>> 
>> 
>> In der Tat. Ich weiß nicht, welche der beiden Firmwares dafür 
>> veranwortlich ist, aber ich habe mit zwei alten Linksys, einer 
>> mit Freifunk, einer mit BFV früher ähnliche Beobachtungen über 
>> eine relativ kurze Strecke gemacht, habe es aber anderen
>> Faktoren zugeschrieben.
>> 
>> 
>> Gibt es von unseren Experten hierzu weitere Informationen? 
>> Funktionsweise, Hintergründe, Ausblick, Lösungen, Standards? Vor 
>> allem:
>> 
>> 1. Soll der Multicast eingestellt werden? 2. Was sehen die 
>> jeweiligen Firmwares als Default vor? 3. Liegt womöglich ein Bug 
>> in einer oder beiden Firmwares vor? 4. Ist das Problem 
>> Ad-hoc-Mode-spezifisch? 5. Wäre 802.11s hiervon ebenso 
>> betroffen?
>> 
>> Ich liebäugle immer mehr mit VIF/AP und 
>> VIF/Client-Konfigurationen, da hierbei der Master die 
>> Entscheidungen trifft und moderne Hardware das schafft. Auch die 
>> älteren Geräte wie der Linksys können zugleich AP und Client 
>> sein, während Ad-Hoc auf ihnen exklusiv laufen muss - angenehmer 
>> Nebeneffekt, wäre weniger Airtime und verminderte 
>> Hidden-Station-Probleme.
>> 
>> 
>> 
>> 
>> Am 13.05.2012, 15:01 Uhr, schrieb Christian Bruckner 
>> <(spam-protected) <mailto:(spam-protected)>>:
>> 
> nein die stehen 1,5m auseinander und haben noch die 
> Originalantennen
> 
> 
> gerhard poller schrieb:
> 
> baum im weg  ?
> 
> wirkt sich asymetrisch aus hab mal künsterisch n bild gezeichnet
> 
> sieh rote und blaue funk linien die sich im baum brechen
> 
> ;))) hf akku
> 
> Am 13.05.2012, 14:23 Uhr, schrieb Christian Bruckner 
> <(spam-protected) <mailto:(spam-protected)>>:
> 
> Seit dem letzten einseitigen Update ist die Kommunikation stark 
> beeinträchtigt.
> 
> http://wlan01.mi001.wien.__funkfeuer.at/cgi-bin/luci/__freifunk/olsr/neighbors/
>
>
> 
<http://wlan01.mi001.wien.funkfeuer.at/cgi-bin/luci/freifunk/olsr/neighbors/>
> 
> 
> 
> 
> 
> 
> Hat jemand eine Idee woran das liegen kann. Es geht um den wlan02 
> Nachbar
> 
> 
> Danke und
> 
> Mit liebe/freundliche Grüße Christian Bruckner +43 680 3255220 
> <tel:%2B43%20680%203255220>
> 
> Ebendorferstraße 19 A 2130 Mistelbach
> 
> Von meinem Mobilephone gesendet -- Wien mailing list 
> (spam-protected) <mailto:(spam-protected)> 
> https://lists.funkfeuer.at/__mailman/listinfo/wien 
> <https://lists.funkfeuer.at/mailman/listinfo/wien>
> 
> 
> 
> 
> 
> -- Wien mailing list (spam-protected) 
> <mailto:(spam-protected)> 
> https://lists.funkfeuer.at/__mailman/listinfo/wien 
> <https://lists.funkfeuer.at/mailman/listinfo/wien>
> 
> 
>>> LG Erich
> 
>> 
>> -- Wien mailing list (spam-protected) 
>> <mailto:(spam-protected)> 
>> https://lists.funkfeuer.at/__mailman/listinfo/wien 
>> <https://lists.funkfeuer.at/mailman/listinfo/wien>
>> 
>> 
>> 
>> 
>> 
>> -- Wien mailing list (spam-protected) 
>> <mailto:(spam-protected)> 
>> https://lists.funkfeuer.at/__mailman/listinfo/wien 
>> <https://lists.funkfeuer.at/mailman/listinfo/wien>
>> 
>> 
>> -- Wien mailing list (spam-protected) 
>> <mailto:(spam-protected)> 
>> https://lists.funkfeuer.at/mailman/listinfo/wien
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Gnu Privacy Tools
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPt43eAAoJEEinsCWBGcfaOK0P/RJLy/dHKHmZHy9Y4V7CqctB
qp32Tj+h1Ezx3h3aymh0kHJ26N1hbE9aRrTgbY5rLIzvDibSPa6xqhogdWhHbTTn
/DRppK0aXrsTRHV2doou2A7Vhmi9SxpMogJwQ+KIc9AgKMIHcy0r2W+0p9Or17Sa
i8gtZ+iDe3956UHUEImqrM4SY1g/rumX/hy8J3ySitd9Lh0Sq3BFFOuFqAp+LR7g
odgWCLQTgInT7UsCjMwx/Scubv2b3cYrLoA0Zb24y51h5R3Vxubta/1ki4FOgOzI
nNUIZunMzqALaxqnPu5kbBXsTIoyyC+ejEvVjnVCj6JVxJZSeAUgIm2madeZX1DK
PJEv0zYMXetDlOpoZvCWbFzmWiwitz5DvNL3NYSV1DW1DysP4FRfSpvILR3xdfJb
D2k6YYqPJn4oV13rgEOgv4610J2fRyx6ZpW3n3xwzDTXZCD1qVLPhr1qY68WK4+1
stOg3dSNIKkYbZuN5k2I2oTozwp2PS+i8IHs/5Frtd3pCcwYj4FGunkohoXgig65
+eBkm2K2VoFLPGMvrsotg7S5ivVoeZv/zDBU8Fge4fQHyCRhGnTPx4lCUT8SasZE
1P6ceD94Wti7TOdTCDTDnkYkrJTqtcOT3EIwALdEXDAUqfNQJLs7HatllblHMnOy
1oRCh/1ufLN6ixNX3qzT
=Yxw4
-----END PGP SIGNATURE-----