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…
Hi zusammen,
Hier ein Doodle für ein puppet treffen. Geplant ist derzeit die Server
Infrastruktur mit puppet wieder zu spiegeln. Aktuell fehlen die Module
für das Routing und die netzwerk interfaces. Rene von Bytemine hat sich
bereit erklärt uns bei der puppet Umstellung zu unterstützen.
http://doodle.com/poll/q5t44kwg6wc4zqpn
vg
Tarek
Hi dev's,
ich habe mal unser x86 Image getestet.
Mir ist aufgefallen, dass in /etc/opkg.conf die falsche Architektur eingetragen ist. Lies sich
händisch ändern, wäre jedoch schön wenn es von vorneherein stimmt.
Über den Einbau von zusätzlichen Kernelmodulen würde ich mich auch freuen.
Mein Wunschliste:
Unterstützung für USB-Netzwerkkarten: Namentlich "kmod-usb-net-asix" und Abhängigkeiten "kmod-usb-net", "kmod-usb-core" und "kmod-nls-base" wäre toll.
Lies sich händisch nachinstallieren und nach der Anpassung der Konfigurationsdateien funktionierte
auch das Clientnetzwerk auf der USB Netzwerkkarte. Löppt.
Atheros Wlan Karten: Namentlich "kmod-ath5k" sowie die Abhängigkeiten "kmod-crypto-aes", "kmod-cfg80211", "hostapd-common", "kmod-mac80211" und "kmod-ath".
Konnte ich nachträglich installieren, wurde von gluon jedoch nicht integriert/angenommen.
Im Configmode zeigte das Webinterface im Reiter Wlan des Expertenmodus nur eine Fehlermeldung von
luci.
/usr/lib/lua/luci/dispatcher.lua:190: Failed to execute cbi dispatcher target for entry '/admin/wifi-config'.
The called action terminated with an exception:
/usr/lib/lua/luci/model/cbi/admin/wifi-config.lua:22: attempt to index field 'nl80211' (a nil value)
stack traceback:
[C]: in function 'assert'
/usr/lib/lua/luci/dispatcher.lua:190: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:63: in function </usr/lib/lua/luci/dispatcher.lua:63>
Über eine kurze Rückmeldung würde ich mich freuen. Damit ich weiß ob ihr das realisieren könnt oder
ich mir das selbst kompilieren muss. (Für die Zukunft).
Danke
Gruß Pascal
PS: Bin nicht auf der Liste Antwortet mir bitte direkt.
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 Leute,
ich hab heut Abend mit Johannes (aka. PowerPan) und Christian (aka.
picard / fr32k) darüber gesprochen,
dass der Konfigmodus wohl eher ein Noteinstieg in die
Routerkonfiguration ist, für den Fall dass man sich für die an-
deren Wege ausgesperrt hat. Denn für den Laien, ist es viel zu
Kompliziert die Einstellungen zwischendurch zu ändern.
Auch für uns Profis, wäre es einfacher bestimmte Einstellungen in der
Weboberfläche vorzunehmen, als über SSH.
Für diesen Zweck fänd ich es schön, wenn die Weboberfläche auch im
normalen Betriebsmodus zu erreichen wäre. -
Natürlich nur wenn bei der Ersteinrichtung ein Passwort eingerichtet
wurde...
Wie kompliziert wäre eine solche Umstellung?
Grüße aus Wilhelmshaven
Malte
Moin
Christian hatte es ja schon geschrieben, dass das Statistik Modul von mir Online ist
Habe das heute nochmal geupdatet.
Bei Verbesserungsvorschlägen bitte ein Issue auf GitHUB schreiben
https://github.com/PowerPan/Freifunk-Node-Clients-stats?files=1
Gruß
Johannes
Von meinem iPhone gesendet
Hallo,
seit einer Weile beobachte ich jetzt starke Schwankungen in der
Netzwerklatenz. Fühlt sich schon fast wie eine Sinuskurve an. In der
Spitze ist sie öfter mal bei 30s. Exemplarisch habe ich unten so eine
"Beuele" angehängt. Habt ihr da etwas "kaputtgespielt" ? :)
Viele Grüße,
Jan
64 bytes from 141.1.1.1: icmp_seq=48217 ttl=54 time=93.8 ms
64 bytes from 141.1.1.1: icmp_seq=48218 ttl=54 time=64.3 ms
64 bytes from 141.1.1.1: icmp_seq=48219 ttl=54 time=67.8 ms
64 bytes from 141.1.1.1: icmp_seq=48220 ttl=54 time=90.2 ms
64 bytes from 141.1.1.1: icmp_seq=48221 ttl=54 time=1000 ms
64 bytes from 141.1.1.1: icmp_seq=48222 ttl=54 time=4240 ms
64 bytes from 141.1.1.1: icmp_seq=48223 ttl=54 time=5548 ms
64 bytes from 141.1.1.1: icmp_seq=48224 ttl=54 time=6741 ms
64 bytes from 141.1.1.1: icmp_seq=48227 ttl=54 time=12776 ms
64 bytes from 141.1.1.1: icmp_seq=48228 ttl=54 time=13086 ms
64 bytes from 141.1.1.1: icmp_seq=48229 ttl=54 time=12839 ms
64 bytes from 141.1.1.1: icmp_seq=48230 ttl=54 time=12342 ms
64 bytes from 141.1.1.1: icmp_seq=48231 ttl=54 time=11970 ms
64 bytes from 141.1.1.1: icmp_seq=48232 ttl=54 time=11917 ms
64 bytes from 141.1.1.1: icmp_seq=48233 ttl=54 time=13362 ms
64 bytes from 141.1.1.1: icmp_seq=48235 ttl=54 time=11373 ms
64 bytes from 141.1.1.1: icmp_seq=48236 ttl=54 time=10407 ms
64 bytes from 141.1.1.1: icmp_seq=48237 ttl=54 time=10114 ms
64 bytes from 141.1.1.1: icmp_seq=48238 ttl=54 time=9917 ms
64 bytes from 141.1.1.1: icmp_seq=48239 ttl=54 time=9643 ms
64 bytes from 141.1.1.1: icmp_seq=48240 ttl=54 time=9129 ms
64 bytes from 141.1.1.1: icmp_seq=48241 ttl=54 time=8352 ms
64 bytes from 141.1.1.1: icmp_seq=48242 ttl=54 time=7615 ms
64 bytes from 141.1.1.1: icmp_seq=48243 ttl=54 time=6986 ms
64 bytes from 141.1.1.1: icmp_seq=48244 ttl=54 time=6183 ms
64 bytes from 141.1.1.1: icmp_seq=48245 ttl=54 time=5517 ms
64 bytes from 141.1.1.1: icmp_seq=48246 ttl=54 time=4517 ms
64 bytes from 141.1.1.1: icmp_seq=48247 ttl=54 time=3720 ms
64 bytes from 141.1.1.1: icmp_seq=48248 ttl=54 time=2968 ms
64 bytes from 141.1.1.1: icmp_seq=48249 ttl=54 time=2220 ms
64 bytes from 141.1.1.1: icmp_seq=48250 ttl=54 time=1474 ms
64 bytes from 141.1.1.1: icmp_seq=48251 ttl=54 time=697 ms
64 bytes from 141.1.1.1: icmp_seq=48252 ttl=54 time=71.0 ms
64 bytes from 141.1.1.1: icmp_seq=48253 ttl=54 time=64.8 ms
64 bytes from 141.1.1.1: icmp_seq=48254 ttl=54 time=72.3 ms
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/
