Hi,
in 0.6.2 gibt es nur eine kleine Änderung. Damit die Netmon
geokoordinaten Synchronisation in der Firmware funktioniert.
Die Router Koordinaten aus Netmon werden mit einer Priorität auf die
Router synchronisiert[0].
Schöne Grüße
Tarek
[0]
https://git.nordwest.freifunk.net/ffnw/packages/commit/f26e4a62aa5842ca5c27…
hallo zusammen,
adrian hat mich auf etwas aufmerksam gemacht bei einem treffen.
aber aus ihrgend einem grund wird es nie zu ende diskutiert?!
Ein Problem ist, dass immer mehr WLAN-Router auf den Markt kommen bei
denen Kanalbündelung (20 MHz + 20 MHz = 40 MHz) aktiviert ist. Hier
werden die Kanäle 1 und 5 sowie 9 und 13 zu je 40 MHz zusammengefasst,
um eine größere Übertragungsgeschwindigkeit zu erreichen. In der
Praxis ist das in der Form meist unnötig. Geht man von einer normalen
WLAN-Nutzung für den Internet-Zugang aus, dann ist die
Übertragungskapazität mit einem 20-MHz-Kanal vollkommen ausreichend.
Dummerweise sind die meisten WLAN-Router nicht in der Lage die
Kanalbreite automatisch herunterzuschalten. Die Bestimmungen für 40
MHz breite Kanäle im 2,4-GHz-Band sind viel zu freigiebig.
quelle: http://www.elektronik-kompendium.de/sites/net/1712061.htm
Hinweis: Gilt, wenn es im Frequenzspektrum extrem eng zu geht: Zwei
WLAN-Netze mit gleichem Kanal stören sich am wenigsten. Liegen die
Kanäle halb übereinander, dann nimmt das eine WLAN das andere als
Störung war und versucht mit niedriger Modulation und maximaler
Sendeleistung das jeweils andere zu übertönen. So stören sich die
WLANs gegenseitig. Deshalb lieber einen belegten Kanal benutzen, als
irgendwas dazwischen. Einen Kanal außerhalb der üblichen
Kanalverteilung zu verwenden ist kontraproduktiv und senkt nur die
Übertragungsrate für alle WLAN-Netze in der näheren Umgebung.
in der siteconf
https://git.nordwest.freifunk.net/ffnw/siteconf/blob/master/site.conf
finde ich htmode = 'HT40+',
unter http://wiki.openwrt.org/doc/uci/wireless#common_options
finde ich htmode mit erklärung
ich bin der meinung wir sollten 20Mhz für ffnw einrichten.
ich kopiere noch mal adrians unterhaltung mit mir und seine zitate aus
der ML hier rein.
Das Thema habe ich bereits 3/4 mal angesprochen, aber leider wurde es
jedes mal wieder verworfen. Im letzten Jahr hatte dann irgendwer (ich
meine es war Tarek) den HT40+ Modus mal aus der Firmware
rausgeschmissen, es aber nur für das Client Netz übernommen, nicht für
das mesh.ffnw Netz. Ein Update später war es dann wieder alles HT40+.
Dann hat Clemens sich im Frühjahr das Thema nochmal aufgegriffen, aber
darauf hat bis heute keiner geantwortet. (siehe weiter unten)
meinst du das?
Ein Problem ist, dass immer mehr WLAN-Router auf den Markt kommen
…praktisch jeder Router, der 802.11n unterstützt…
bei denen Kanalbündelung (20 MHz + 20 MHz = 40 MHz) aktiviert ist.
Hier werden die Kanäle 1 und 5 sowie 9 und 13 zu je 40 MHz
zusammengefasst, um eine größere Übertragungsgeschwindigkeit zu
erreichen. In der Praxis ist das in der Form meist unnötig. Geht man
von einer normalen WLAN-Nutzung für den Internet-Zugang aus, dann ist
die Übertragungskapazität mit einem 20-MHz-Kanal vollkommen
ausreichend. Dummerweise sind die meisten WLAN-Router nicht in der
Lage die Kanalbreite automatisch herunterzuschalten. Die Bestimmungen
für 40 MHz breite Kanäle im 2,4-GHz-Band sind viel zu freigiebig.
quelle: http://www.elektronik-kompendium.de/sites/net/1712061.htm
<http://www.elektronik-kompendium.de/sites/net/1712061.htm>
Richtig, so ist es! Ich habe es schon oft versucht, auf
Freifunktreffen im Space zu erklären, da es sich dabei wirklich um ein
doofes Problem handelt. Meist hieß es dann leider, das 40Mhz ja immer
auf jeden Fall besser wären als ‘nur’ 20 Mhz. Grade auf
Großveranstaltungen habe ich dann händisch alle 2,4Ghz Knoten auf HT20
zurück gefahren, um mit Freifunk nicht das komplette Frequenzband zu
belegen. Denn je breiter unser Funkkanal ist, desto anfälliger ist er
natürlich auch für Störungen. Und grade, weil wir dann mit unserem 6+1
(HT40+) quer durchs Funkband senden, ist mir das schon immer ein Dorn
im Auge gewesen. Wir sollten uns an den Standart 1 - 6 - 11 halten und
dabei die jeweils höheren bzw niedrigeren Kanäle nicht stören. (meint
Kanal 6 HT20)
Hinweis: Gilt, wenn es im Frequenzspektrum extrem eng zu geht: Zwei
WLAN-Netze mit gleichem Kanal stören sich am wenigsten. Liegen die
Kanäle halb übereinander, dann nimmt das eine WLAN das andere als
Störung war und versucht mit niedriger Modulation und maximaler
Sendeleistung das jeweils andere zu übertönen. So stören sich die
WLANs gegenseitig. Deshalb lieber einen belegten Kanal benutzen, als
irgendwas dazwischen. Einen Kanal außerhalb der üblichen
Kanalverteilung zu verwenden ist kontraproduktiv und senkt nur die
Übertragungsrate für alle WLAN-Netze in der näheren Umgebung.
Genau das tut es dann bei uns auch, denn wir benutzen ja quasi den
Kanal 6 plus die höheren anliegenden 20Mhz welche sich nicht mit einem
WLAN auf Kanal 11 deckt und so auch wieder zu Störungen führt. Die
quellen, die du genannt hast, belegen das ja…
http://www.dd-wrt.com/wiki/index.php/Wireless-N_Configuration
<http://www.dd-wrt.com/wiki/index.php/Wireless-N_Configuration>
http://www.smallnetbuilder.com/wireless/wireless-features/31743-bye-bye-40-…
<http://www.smallnetbuilder.com/wireless/wireless-features/31743-bye-bye-40-…>
Viele Communitys haben bereits auf HT20 umgestellt, und wir sollten
die nächste sein :)
Hier nochmal Copy-Paste von der ML Month ago:
Ja, es geht mir darum, dass 2,4 Ghz Netz mit Freifunk nicht zu stark
zu verschmutzen.
Aktuell gibt es unter den Routerherstellern wie Telekom, AVM, und
anderen die Vereinbarung, im 2,4Ghz Band lediglich mit den Kanälen 1,6
und 11 zu arbeiten (Ein Kanal = 5Mhz, 20 Mhz Kanalbreite = belegt bis
zu 5 Kanäle) und auf dem im 802.11n Standart standardisierten HT40
Modus zu verzichten. So können drei HT20 Netze störungsfrei
koexistieren. Wenn nun 2 Wlannetze auf dem gleichen Kanal senden, ist
es außerdem so, dass die sich bei der Sendezeit abstimmen und so
nacheinander senden können und nicht gegenseitig sich 'anschreien'.
Das funktioniert nicht, wenn WLAN A auf Kanal 5 und WLAN B auf Kanal 6
arbeitet. Die Freifunkrouter senden aktuell auf dem Kanal 6+1 also
benutzen zusätzlich die oberhalb von Kanal 6. Dieser erweiterte 20Mhz
Kanal ist aber nicht deckungsgleich mit einem WLAN, welches auf Kanal
11 sendet. So sorgen wir aktuell mit unserem mesh.ffnw Netz dafür, das
die oberen Kanäle gestört werden und noch schlechter bis gar nicht
koexistieren können.
Zur Übertragungsgeschwindigkeit: Mit Sicherheit ist es so, dass die
meshgeschwindigkeit mit 40Mhz Bandbreite höher ist (Brutto 300 Mbits
auf 130 Mbits) Aber grade in Städten, wo ja nun sicher 90 Prozent der
Freifunknodes stehen, funkt mindestens eine Fritze auf Kanal 11 und
stören unsere, aber wir auch dessen Netz. Daher befürworte ich lieber
ein Funknetz, das sich mit seinen Nachbarn abspricht als eins, das
sich selbst und andere Funknetze stört.
Im 5Ghz Band ist das wieder etwas anderes, da dort genug Bandbreite
auch für HT40 Netze bereithält. Dort können wir weiterhin mit Kanal
44+1 senden.
Wir hatten das Thema ende letzen Jahres bereits mal auf einem Treffen
besprochen, wohin dann auch das Clientnetz auf HT20 umgestellt worden
ist. Aber iwie hat man es fürs meshnetz nicht gemacht/vergessen
Am 12.04.2015 um 16:12 schrieb Clemens John <clemens.john(a)floh1111.de>:
[Zitattext verstecken]
Am Samstag, 11. April 2015, 12:19:35 schrieb Patrick Uven:
Moin,
On 11.04.2015 12:02, Clemens John wrote:
anscheinend gibt es ein Problem mit dem aktuellen htmode (HT40+), das wir
hier kurz in einem eigenen Thread diskutieren sollten.
gibt es irgendwo ein Zitat/Link mit dem Problem?
Da müsste Adrian sich mal zu äußern. Genaues weiß ich auch nicht.
LG
Clemens
Ich würde mich freuen, wenn wir diese Diskussion endlich mal zu Ende
bringen könnten :))
Liebe Grüße
Adrian
--
Gruß
pic
@ME https://wiki.nordwest.freifunk.net/picard
Hi,
ich hab den Master mal gebaut[0]. Eine interessante Änderung ist, das
wir jetzt parallel 802.11s und Ad Hoc im Mesh fahren.
Die Firmware ist wirklich experimental. Z.B. funktionieren unsere ffnw
spezifischen packages nicht. Das ist mir allerdings erst im Nachhinein
aufgefallen.
Manuell kann man den folgends fixen:
mv /lib/gluon/cron/* /usr/lib/micron.d/
vg
Tarek
[0]
http://firmware.ffnw.de/
Hi,
@Eike:
Ich habe ein paar Feinheiten angepasst und baue jetzt ein testing Image
mit dem nodewatcher2. Der Code sieht abgesehen von so ein paar
whitespace Sachen sehr gut aus.
vg
Tarek
Hi,
falls Interesse besteht. Ich bin heute den ganzen Abend im Hackspace und
werde mich weiter um puppet module und firmware kümmern. Falls mir
jemand Gesellschaft leisten will und mitmachen will freue ich mich ;)
vg
Tarek
Guten Tag, Leider bin ich Zeitbedingt nach wie vor etwas inaktiv haette aber ein paar Fragen zur autmatischen Positionsbestimmung der Router. Im Speziellen geht es um die Router: https://mesh.ffnw.de/#!v:m;n:68725124e56a und https://mesh.ffnw.de/#!v:m;n:0027229c08f0 Beide befinden sich ausgerichtet nach Namensgebung an einer Halterung(Abstand wenige cm) und haben die automatische Positionsbestimmung aktiviert. Zu den Fragen: Ist die Positionsangabe im Meshviever korrekt? Wie kommen die die starken Differenzen zustande? Ich habe mit der App von OpenWlanMap bereits das umligende Gebiet gemappt(separates Handy im Auto mit automatischem Upload bei 5000 Eintraegen und WLAN(sprich Autoupload abends wenn ich vor der Haustuer Parke)). Kann ich noch etwas tun um die Positionierung zu verbessern(da die Positionen im Meshviewer nichtmal ansatzweise stimmen)? MfG Jan
-------------------------------------------------------------------------------------------------
FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT
hallo,
ich besitze einen rpi2 und habe interesse dort eine freifunk fw drauf
zu testen.
auf die idee gekommen bin ich von einem nicht freifunker der fragte
mich ob wir auch images für
Einplatinen-Computer wie Raspberry Pi, Banana Pi oder Cubieboard haben.
ich habe im forum etwas gelesen
https://forum.freifunk.net/t/gluon-target-raspberry-pi-und-banana-pi-brcm27…
möglich soll es sein, hat jemand freifunk auf einem
Einplatinen-Computer am laufen?
ich würde mich freuen wenn wir dafür auch images hin bekommen.
--
Gruß
pic
@ME https://wiki.nordwest.freifunk.net/picard
Hi,
mir ist ein Fehler beim build process unterlaufen. In der 0.6.1 ist die
netmon geo syncronisation nicht enthalten da in meinem build root noch
ein gecachtes package vom cunfigurator enthalten war. Nun bin ich am
überlegen ob ich ein 0.6.2 Firmware baue und nur den fix für die geo
syncronisation einbaue.
Die andere Variante wäre folgende:
Es besteht schon seid ein paar Wochen die Anfrage für einen Hardware
support für den wr841n* v10 und der cpe* v1.1 diese werden allerdings
nur im Aktuellen Chaos Calmer supported da der ath9k Treiber in Barrier
Breaker zu alt ist.
Wir könnten nun von v2015.1.x auf den master branch (somit auf dev )
wechseln. Dann würde ich direkt eine 0.7 Firmware bauen und dort auch
den geo sync fix mit einbauen. Allerdings soll im November v2015.2.x
released werden, dort wäre der support für die o.g Hardware enthalten.
Jetzt ist meine frage ob wir auf das release warten oder jetzt auf dev
wechseln wollen?
vg
Tarek
