- Dev - Freifunk Nordwest

Bitte Firmware 0.6.2 signieren
by Clemens John 05 Dec '15

05 Dec '15

Hi, die Firmware Version 0.6.2 wartet noch auf die Signatur von einer Person. Evtl. ist das etwas untergegangen, ich habs auch erst durch den Anruf von Stefan bemerkt. Dokumentation zum Signieren: https://wiki.nordwest.freifunk.net/Entwicklung/Firmware_releaseprozess#Best… Firmware Download: http://firmware.nordwest.freifunk.net/0.6.2/ Viele Grüße Clemens

7 8

Space netz
by Jan-Tarek Butt 04 Dec '15

04 Dec '15

Hi, ich bin gerade im space und prüfe die Problematik mit Freifunk. tata@keks ~ % speedtest-cli Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Leaseweb Deutschland GmbH (178.162.198.45)... Selecting best server based on latency... b'Hosted by HillCom Solutions (Alsfeld) [33.58 km]: 72.562 ms' Testing download speed........................................ Download: 7.85 Mbit/s Testing upload speed.................................................. Upload: 5.67 Mbit/s Speedtest ist ok. keks (0.0.0.0) Fri Dec 4 23:48:27 2015 Resolver error: Received reply from unknown source: fd74:fdaa:9dc4::q uit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 10.18.40.1 7.1% 56 82.5 66.4 36.8 166.2 28.7 2. 10.4.0.1 9.1% 56 81.5 66.7 37.6 165.9 24.3 3. vlan436.fra1-ngn-cs2. 1.8% 56 124.7 65.0 36.1 124.7 20.9 4. 178.162.223.136 1.8% 56 86.6 71.0 37.7 183.6 24.4 5. te0-1-1-5.nr21.b01575 3.6% 56 111.0 67.5 37.3 157.9 26.4 6. be2258.rcr21.fra06.at 3.6% 56 90.6 65.4 38.6 105.9 19.1 7. be2305.ccr42.fra03.at 1.8% 56 100.2 63.9 38.6 193.6 27.0 8. be2262.ccr42.ams03.at 0.0% 56 90.0 69.8 46.6 132.7 19.8 9. be2183.ccr22.lpl01.at 3.6% 56 87.1 77.1 56.0 105.3 13.8 10. be2191.ccr21.man01.at 5.4% 56 106.6 83.6 56.3 168.7 24.0 11. te1-4.ccr01.man02.atl 8.9% 56 117.9 117.4 57.8 302.0 63.1 12. 149.14.36.18 1.8% 56 71.5 87.8 61.1 181.2 28.5 13. te0-1.cr1.lds.bytemar 5.5% 55 134.3 87.2 60.2 161.5 25.8 14. te1-6.cr1.yrk.bytemar 3.6% 55 107.1 94.3 60.7 195.3 30.4 15. po1.ar1.dc1.yo26.yrk. 1.8% 55 112.5 87.4 60.9 222.2 29.2 16. www.gentoo.org 3.6% 55 113.1 92.1 59.2 193.5 28.7 mtr über v4 ist unproblematisch My traceroute [v0.86] keks (::) Fri Dec 4 23:47:40 2015 Keys: Help Display mode Restart statistics Order of fields uit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 2a03:2260:1001::24:1 1.4% 841 88.9 97.5 69.8 291.0 22.3 2. 2a03:2260:0:1e::1 9.0% 841 112.7 126.1 96.2 1081. 41.8 3. 2001:7f8:19:1::1b1b:1 9.9% 841 149.0 136.5 97.1 373.8 27.8 4. 10ge11-5.core1.ams1.h 9.5% 841 132.1 147.5 121.0 858.2 34.2 5. ams-ix-v6.nl.plusline 56.9% 841 137.1 149.8 120.7 373.9 24.8 6. te3-2.c501.f.de.plusl 10.1% 841 148.9 154.5 112.8 418.1 42.3 7. te2-4.c101.f.de.plusl 10.6% 841 129.8 156.3 122.2 384.5 40.1 8. 2a02:2e0:3fe:0:c::1 9.3% 841 148.7 151.4 120.4 390.4 30.4 9. redirector.heise.de 10.0% 840 146.5 146.2 120.9 381.2 27.9 Bei v6 gibt es an 5. stelle ~60% packagelost. Es könnte an der Telekom störung liegen (siehe golem). Ich bin mir da allerdinst nicht sicher. Hat jemand ne idee? vg Tarek

1 0

Changelog 0.6.2
by Jan-Tarek Butt 27 Nov '15

27 Nov '15

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…

5 29

dev Treffen für Puppet Umstellung
by Jan-Tarek Butt 25 Nov '15

25 Nov '15

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

2 1

Rückmeldung zum Test von x86 gluon Image
by heynmoeller＠gmx.net 22 Nov '15

22 Nov '15

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.

1 0

Freifunk wlan Mhz 40/20
by picard 18 Nov '15

18 Nov '15

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

3 4

Konfigmodus=Notfallmodus? / Weboberfläche im Betriebszustand
by Malte Modler 14 Nov '15

14 Nov '15

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

2 2

Statistik
by Johannes Rudolph 13 Nov '15

13 Nov '15

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

1 0

Latenz-Schwankungen
by Jan Murawski 13 Nov '15

13 Nov '15

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

1 0

0.7 experimental
by Jan-Tarek Butt 02 Nov '15

02 Nov '15

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/

2 3