March 2016 - Dev - Freifunk Nordwest

repo namespace änderung
by Jan-Tarek Butt 25 Mar '16

25 Mar '16

Hi, ich habe soebend den hoodgen von eike in den ffnw-server namespace verschoben. https://git.nordwest.freifunk.net/ffnw-server/hoodgen wer einen locales repo geclont hat muss bitte seinen remote url aktualisieren. Schöne Grüße :) Tarek

1 0

MTU detection
by Tim Leerhoff 24 Mar '16

24 Mar '16

Hallo Gerrit, meine Mail an deine direkte E-Mail ist leider zurückgekommen. Deshalb hier nochmal über die Mailingliste. Ich möchte Dein Angebot annehmen. Es wäre toll, wenn Du mir Zugangsdaten(IP,User,Pwd) für einen der Router (am liebsten erstmal den TPLINK841N) geben würdest, damit ich ein file (mtudetect) manuell draufkopieren kann. Dieses würde ich dann erstmal gerne von Hand ausprobieren, da dann das debugging etwas einfacher ist Danke für die Hilfe ! Gruß Tim

1 0

[Ticket #614525]
by Malte Modler 19 Mar '16

19 Mar '16

Hallo, ich hab vor einer kurzen Weile ein Ticket eröffnet mit folgendem Problem, zu dem ich bisher keine Lösung habe. Das Ticket wurde jedoch schon geschlossen. Deswegen möchte ich es nochmal auf der Mailingliste versuchen. LG Malte > Das Problem betrifft "whv-familienzentrum-west-2". Dieser ist über > whv-familienzentrum-west-1 gemesht, er bekommt jedoch selbst keine > IPv6-Adressen (somit ist er über SSH nicht zu warten und er bekommt > auch keine Updates) Die Clients und der Meshviewer sind davon > unbeeindruckt. > Das Problem bestand auch schon bevor das Update auf 0.6.2 freigegeben > wurde. > > Fakten zu whv-familienzentrum-west-1 > Hardware: TP-Link TL-WDR3600 v1 > Software: 0.6.2 / gluon-v2015.1.2-4-gcc0c1d2 > Verbindung ins Internet per "Mesh-VPN" (wie ist normalerweise bei > jedem Router ist) > Verbindung zum "whv-familienzentrum-west-2" über "Mesh on LAN" > > Fakten zu whv-familienzentrum-west-2 > Hardware: TP-Link TL-WR841N/ND v9 > Software: 0.6.1 / gluon-v2015.1.2-2-g8db1e73 > Verbindung zu "whv-familienzentrum-west-1" per "Mesh on WAN".

2 6

Changelog 0.8 die zweite
by Jan-Tarek Butt 16 Mar '16

16 Mar '16

Hi, Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 0.8 * Gluon-Version: gluon2016.1.x * Download: http://firmware.ffnw.de/0.8/ Folgende Änderungen gab es in gluon: * Hinzu gekommener Hardware Support: ar71xx-generic * Onion Omega Buffalo WZR-HP-G300NH D-Link DIR-505 (A1) TP-Link CPE210/220/510/520 v1.1 TL-WA901N/ND v1 TL-WR710N v2 TL-WR801N/ND v1, v2 TL-WR841N/ND v10 TL-WR843N/ND v1 TL-WR940N v1, v2, v3 TL-WR941ND v6 TL-WR1043N/ND v3 TP-Link TL-MR13U v1 Ubiquiti airGateway airRouter UniFi AP Outdoor+ Western Digital My Net N600 My Net N750 * Fehlerbehebung * opkg reposetory key wird nicht bei sedem build überschreiben. * AirOS 5.6.x Kompatibilität * das Downgraden zu AirOS 5.5.x bevor Gluon auf Airmax M XM/XW Geräten gefläsht wird (NanoStation, Bullet, ...) ist nicht mehr notwendig. * Status seite * Behebt das entfernen von verschwundenen Nodes aus der liste. * Der Signal Graphen wird nun korrekt auf mobielen Browsern dargestellt. * Höhere Browser Kompatibilität * Config mode * Entfernt Leerzeichen aus nummern Feldern (Der LuCI Validator prüft nicht auf Leerzeichen) * Negatives Bandbreiten Limit ist nun nicht mehr möglich. * Failsafe mode * Das entern des failsafe mode auf dem TL-WDR4900 ist nun möglich. Details zu den Änderungen siehe auf: https://gluon.readthedocs.org/en/v2016.1.1/releases/v2016.1.1.html Folgende Nordwest spezifische Änderungen gab es: * IEEE 802.11s wurde entfernt. * Der geolocator wurde auf Standart Enable gesetz. * Das package gluon-announced wurde durch gluon-respondd ersetzt. * Das package ffnw-opkgconfig wurde entfernt. * Fastd publickey ist im configmode wieder Sichbar. * Signatur publickeys von bioxz und pic sind entfernt worden. * Signatur publickeys von fkr und PowerPan sind hinzugefügt worden. * Signatur publickeys von runner02.ffnw.de in in testing hinzugefügt worden für gitlab-CI. * Das package ffnw-configurator wurde entfernt. * Das package ffnw-nodewatcher wurde entfernt. * Folgende packages sind in der x86-generic architecture hinzu gekommen: * kmod-usb-core * kmod-usb2 * kmod-usb-hid * kmod-usb-net * kmod-usb-net-asix * kmod-usb-net-dm9601-ether Die Änderungen an der Siteconf können im Siteconf-Repo mittels folgendem Befehl eingesehen werden: git diff v0.6.2 v0.8 Die Änderungen an unseren eigenen Paketen können im Packages-Repository mittels folgendem Befehl eingesehen werden: git diff v0.6.2 b472c22a1f878c51ddb5a8713c6bfea525d564e5 Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Entwicklung/Firmware_releaseprozess#Firm… Viele Grüße Tarek

4 8

Mesh- und Client-Netz
by Malte Modler 16 Mar '16

16 Mar '16

Hallo, mir ist gerade ein kleines Malheur passiert, ich wollte zwei Freifunkrouter per LAN meshen lassen, dabei hab ich aber versehentlich das Client-Netz mit dem Mesh-Netz verbunden. Hätte dies auf längere Zeit Probleme verursacht? Und falls ja, ist dies vielleicht schon jetzt irgendwem, irgendwo, unerkannt passiert? Und ist dies evtl. eine Mitursache für das labile Netz als ganzes? LG Malte

2 1

Autolocator Fix
by Johannes Rudolph 15 Mar '16

15 Mar '16

Moin zusammen, ich habe gerade meinen Autolocator Fix [1] getetset, das sieht ganz vielversprechend aus. Ich würde mich freuen wenn der eine oder andere es auch noch testen würde. Ich habe eine Testfirmware dafür gebaut und würde sie euch auf Anfrage dementsprechend zusenden so dass wir noch ein paar Referenz werte haben. Ich freue mich auf zahlreiche Leute die "hier" schreien. Gruß Johannes [1] https://git.nordwest.freifunk.net/ffnw-firmware/packages/merge_requests/5

2 1

puppet Development Prozess #22
by Jan-Tarek Butt 14 Mar '16

14 Mar '16

Hi, Ich würde gerne nochmal an das Ticket erinnern. Wenn wir dafür ein Workaround finden können wir den v0.1 Milestone abschließen. vg Tarek

3 5

Autoupdater: Bad Domain
by Jens Ellerbrock - Freifunk Nordwest e.V. 14 Mar '16

14 Mar '16

Hey Leute mir ist aufgefallen, dass 0.8 stable ist, Dankeschön:). Leider melden die Router auf denen ich Zugriff habe alle Bad Domain (Autoupdate.ffnw) Mit freundlichen Grüßen Jens Ellerbrock -------------------- Freifunk Nordwest e.V. Website Unterstütze uns doch mit einer kleinen Spende, oder ganz einfach beim Onlineshoppen (ohne extra Kosten)

5 5

Re: [Dev] Dev Nachrichtensammlung, Band 10, Eintrag 13
by Tim Leerhoff 13 Mar '16

13 Mar '16

Hallo Tarek, von wo aus soll die MTU detection (subtype 13) nachher erfolgen ? Im fastd direkt oder als externes Tool, welches via script aufgerufen wird. >> ich arbeite gerade an einer Lösung zur MTU-detection (packages, Issue #29). >> Meine Lösung sieht das Senden eines Pings mit "don't fragment bit" und >> variierender Paketgröße vor. >> Ich habe einen proof of concept in C unter github: >> >> https://github.com/lethexa/mtudetect >> >> Sollte dies eine Hilfe sein würde ich die Entwicklung und Integation >> gerne weiterführen. > Sehr cool! > > Mein Plan ist die fastd MTU wieder auf 1426 (PPPoE optiemirt) zu setzen. > Hintergrund des MTU detectior ist zu prüfen ob Destination Unreachable > mit Subtyp 13 Communication administratively prohibited kommt. Das > geschieht leider bei DS-Lite Anschlüssen bsp. Kabeldeutschland/Vodafone > und unitymedia weil die sich nicht Standards halten. Würde der Fehler > entsprechend auftreten soll eine MTU von 1312 (unsere aktuelle) gewählt > werden. Evtl. kann man die MTU von 1312 auch größer wählen allerdings > müsste man erst mal mit wireshark oder ähnlichen schauen wie groß die > fastd Pakete samt Header sind und was maximal bei DS-lite Anschlüssen > möglich ist. > > Dein package sieht soweit sehr gut aus, aber es schein ein allgemeiner > MTU detector zu sein den man via shell ausführt richtig ? > Gruß Tim

2 4

Meshviewer SSL
by Simon Kurka 13 Mar '16

13 Mar '16

Hallo zusammen, ich habe gerade SSL beim Meshviewer abgeschaltet, da es Probleme im Zusammenhang mit dem gluon-collector (Ersatz für ffmap-backend) verursacht. Da vom und zum Meshviewer ohnehin keine geheimen Daten übertragen werden ist SSL auch recht überflüssig. Eine Weiterleitung von SSL zu non-SSL ist non-permanent eingerichtet und kann gerne auf permanent umgestellt werden, wenn der zukünftige Umgang diskutiert wurde. Hintergrund der Probleme: Der gluon-collector liefert Daten unverschlüsselt aus (genau so wie die Router die Daten unverschlüsselt und an jeden verteilen). Gibt man den gluon-collector als non-SSL Quelle auf einer SSL Seite an, meckern viele Browser, dass unsichere Quellen eingebunden sind. -- Viele Grüße, Simon

1 0