April 2016 - Dev - Freifunk Nordwest

Signierung 0.8.2
by Johannes Rudolph 23 Apr '16

23 Apr '16

Moin es wäre super wenn einfach alle die es noch nicht getan haben die 0.8.2 signieren würden! Es sind zwar 4 Gültige Signaturen vorhanden, allerdings updaten sich die Router < 0.8 nicht, da diesen zum Beispiel meine Signatur auf Firmware < 0.8 noch nicht bekannt ist. Dadurch stellt der Autoupdater fest, dass noch nicht genügend gültige Signaturen vorhanden sind und updatet nicht. Daher bitte Signieren Danke ! (Das ist ja auch schnell gemacht) Gruß Johannes

5 4

Lass das mal den Buildserver machen
by Clemens John 22 Apr '16

22 Apr '16

Hi, Johannes hat sich mit dem CI System von Gitlab beschäftigt und ein paar Scripte gebastelt, die bei jedem Commit in das siteconf Repo automatisch eine neue Firmware bauen, signieren und unter folgender URL hochladen: http://firmware.nordwest.freifunk.net/nightly/<SITECONF-BRANCHNAME> Ich habe das ganze noch ein wenig überarbeitet und jetzt scharf geschaltet. Die relevanten Dateien zur Konfiguration liegen im siteconf Repo unter: * .gitlab-ci.yml * build/ Dokumentation: * http://doc.gitlab.com/ce/ci/yaml/README.html * Doku im Wiki ist TODO Aktuell ist das Feature für die folgenden Branches aktiviert: * master * citest Jeder der häufig Änderungen an der Firmware testen muss oder neue Dinge entwickelt, kann bei Bedarf einen eigenen Branch im siteconf Repo anlegen und das automatische Bauen der Firmware für den Branch aktivieren indem er den Namen des Branches in seinem Branch im .gitlab-ci.yml Script in den jeweiligen Abschnitten von "only" hinzufügt. Wenn man dann noch die "modules"-Datei auf einen eigenen packages Branch anpasst und einen eigenen Update-Channel in der Siteconf hinzufügt kann man sich damit eine richtig schöne Testumgebung mit automatischem Deployment auf Testroutern realisieren. Builds angucken: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds Viel Spaß damit und viele Grüße Clemens P.S. Da das Artifacts-Feature von Gitlab erst in einer der kommenden Versionen auto removing von Artifacts unterstützen wird, wird die Firmware aktuell nur für den wr841n/d deployed um den Speicherbedarf für Artifacts im Gitlab in Grenzen zu halten.

1 0

Update alter Router
by Johannes Rudolph 20 Apr '16

20 Apr '16

Moin, ich weiß nun warum sich alte Router die noch 0.6x oder so haben nicht updaten, sie kennen die neuen Signaturen nicht. Wie lösen wir das nun am besten? Könnten noch leute die in der 0.6 Firmware die keys hatten bitte noch die 0.8.2 signieren dass sich die noch hängengebliebenden Router updaten, danke ! Gruß Johannes root@oldenburg-stuwo-pferdemarkt16-1:~# autoupdater Connecting to autoupdate.ffnw ([2a03:4000:6:8025::1]:80) - 100% |*******************************| 22144 0:00:00 ETA Not enough valid signatures! No usable mirror found.

1 0

IPv6 auf Router
by Clemens John 15 Apr '16

15 Apr '16

Hi, ich bin in der misslichen Lage, dass ich ein Paket auf dem Router nachinstallieren muss (Firmware ist auf Stand aktueller master). Das Blöde: der Router denkt er sei per IPv6 angebunden und löst demzufolge jede Adresse für die ein AAAA Record existiert auf den AAAA record auf obwohl ich natürlich nur per IPv4 angebunden bin. Ich hatte kurz die Idee IPv6 per sysctl einfach zu disablen, aber dann läuft auch link local nicht mehr. Was kann ich tun? Viele Grüße Clemens

2 4

Sign Request: 0.8.2
by Bjoern Franke 12 Apr '16

12 Apr '16

Hi, Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 0.8.2 * Gluon-Version: 2016.1.3 * Download: http://firmware.nordwest.freifunk.net/0.8.2/ Folgende Änderungen gab es: * vpn-Server wurden von srvxx zu vpnyy geändert vg bjo -- xmpp bjo(a)schafweide.org

4 8

Hoodselector - site.conf - Debug
by Johannes Rudolph 10 Apr '16

10 Apr '16

Moin, zusammen mit Stefan habe ich eine Lösung entwickelt, mit der wir im Meshviewer schnell sehen können welche Router in welcher Hood ist. Dieses wird durch den siteCode in der site.conf gesteuert. Die site.conf ist auch auf dem Router abgesichert und wird von respondd ausgelesen. respondd sammelt die Daten zusammen und sendete sie an Alfred bzw im neuen Setup an den Nachfolger. Demnach müsste die site.conf bei setzten eine Hood durch den Hoodselector angepasst werden. Ich habe dieses auch schon erfolgreich testen können. https://git.nordwest.freifunk.net/ffnw-firmware/packages/blob/feature/SiteC… Was haltet ihr davon? Meinungen? Gruß Johannes

5 13

Stand der Dinge Firmware 0.9
by Johannes Rudolph 10 Apr '16

10 Apr '16

Moin, wie schaut es damit aus? Du wolltest sie ja schon gebaut haben Tarek oder? Gruß Johannes

3 3

BUG: Falsche aus mac automatisch generierte IPV6
by Tverr Bjelke 10 Apr '16

10 Apr '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hallo, ich habe hier mit einem Handy dauernd Verbindungsprobleme und bin dann beim Aufsetzen eines weiteren (baugleichen) Routers auf folgendes Gestoßen: Mein zweiter Router ffnw-tverrbjelke-d85d4c9c2f6e | TP-Link TL-WR1043N/ND v1 http://map.ffnw.de/#!v:m;n:d85d4c9c2f6e Er hat eine andere reale ipv6 als die automatisch bestimmte und in der Map eingetragene! Das gleiche gilt für meinen ersten router ffnw-tverrbjelke-d85d4c9c2da6 http://map.ffnw.de/#!v:m;n:d85d4c9c2da6 auch! Ich habe Tarek auf beiden routern seinen SSH-Key eingetragen, damit er debuggen kann. Ich glaube aber das Problem liegt schon HIER: http://mastersword.de/~reddog/ll.php diese Seite erzeugt aus meiner MAC (genommen jeweils von der Rückseite des routers) eine komische IPv6, aber die tatsächlich im gerät verwendete ipv6 linklocal ist eine andere! ffnw-tverrbjelke-d85d4c9c2da6 mit der MAC DA:5E:4C:9C:2D:A6 komme ich real ran mit: ping6 fe80::d85e:4cff:fe9c:2da6%eth0 In der url generierte und auch in der Map eingetragen als fe80::da5d:4cff:fe9c:2da6 Entsprechend auch falsch bei dem router ffnw-tverrbjelke-d85d4c9c2f6e mit der realen mac DA:5E:4C:9C:2F:6E komme ich ran mit: ping6 fe80::d85e:4cff:fe9c:2f6e%eth0 hier mal ein ifconfig auszug: ############################################################## root@ffnw-tverrbjelke-d85d4c9c2f6e:/etc/dropbear# ifconfig bat0 Link encap:Ethernet HWaddr D8:5D:4C:9C:2F:6E inet6 addr: fe80::da5d:4cff:fe9c:2f6e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:143 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:33 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:6006 (5.8 KiB) TX bytes:0 (0.0 B) br-client Link encap:Ethernet HWaddr D8:5D:4C:9C:2F:6E inet6 addr: fd74:fdaa:9dc4:0:da5d:4cff:fe9c:2f6e/64 Scope:Glob al inet6 addr: fe80::da5d:4cff:fe9c:2f6e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:142 errors:0 dropped:0 overruns:0 frame:0 TX packets:44 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3976 (3.8 KiB) TX bytes:6006 (5.8 KiB) br-wan Link encap:Ethernet HWaddr DA:5E:4C:9C:2F:6E inet addr:192.168.2.123 Bcast:192.168.2.255 Mask:255.255.255 .0 inet6 addr: fe80::d85e:4cff:fe9c:2f6e/64 Scope:Link inet6 addr: 2a02:8109:1880:994:d85e:4cff:fe9c:2f6e/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1222 errors:0 dropped:0 overruns:0 frame:0 TX packets:866 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:201027 (196.3 KiB) TX bytes:143936 (140.5 KiB) client0 Link encap:Ethernet HWaddr DA:5F:4D:9C:2F:6E inet6 addr: fe80::d85f:4dff:fe9c:2f6e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:158 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:10464 (10.2 KiB) eth0 Link encap:Ethernet HWaddr D8:5D:4C:9C:2F:6E inet6 addr: fe80::da5d:4cff:fe9c:2f6e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1293 errors:0 dropped:3 overruns:4595 frame:0 TX packets:1038 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:227559 (222.2 KiB) TX bytes:158205 (154.4 KiB) Interrupt:4 eth0.1 Link encap:Ethernet HWaddr DA:5E:4D:9C:2F:6E UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:164 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:8288 (8.0 KiB) eth0.2 Link encap:Ethernet HWaddr D8:5D:4C:9C:2F:6E UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1290 errors:0 dropped:0 overruns:0 frame:0 TX packets:866 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:204155 (199.3 KiB) TX bytes:143936 (140.5 KiB) ibss0 Link encap:Ethernet HWaddr DA:60:4D:9C:2F:6E inet6 addr: fe80::d860:4dff:fe9c:2f6e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1532 Metric:1 RX packets:1080 errors:0 dropped:0 overruns:0 frame:0 TX packets:1141 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:56232 (54.9 KiB) TX bytes:80604 (78.7 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:1292 errors:0 dropped:0 overruns:0 frame:0 TX packets:1292 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:117064 (114.3 KiB) TX bytes:117064 (114.3 KiB) local-node Link encap:Ethernet HWaddr 16:41:95:40:F7:DC inet6 addr: fe80::1441:95ff:fe40:f7dc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:142 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:5964 (5.8 KiB) TX bytes:738 (738.0 B) mesh-vpn Link encap:Ethernet HWaddr DA:61:4C:9C:2F:6E inet6 addr: fe80::d861:4cff:fe9c:2f6e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1312 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:581 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 B) TX bytes:39186 (38.2 KiB) - ---- Ihr werdet sowieso nie begreifen, daß Denken kein bloßer Zeitvertreib, sondern eine Pflicht ist... (Pfeffer) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAlcKLtMACgkQRP30d5yulgHn/AD+K70L6NwNlslJW2X2Ao4ILtJp IbEz5gieWiBIWzYflP8A/Resc9LnroZ16cyNMmn52JODIwuJ9MpGsMJTOeuJmtk4 =oqQC -----END PGP SIGNATURE-----

1 0

hoodselector
by Jan-Tarek Butt 10 Apr '16

10 Apr '16

Hi, ich habe mir nach dem letzten Arbeitstreffen den hoodselector nochmals angeschaut und durch gespielt. https://pad.ffnw.de/p/hoods-testcases (Ab den Punkt Hoodselector evaluirungsphase) Wir haben in dem Pad vor ein paar Wochen test-cases eruiert. Es fehlt im Grunde ein testcase wo Clemens und ich, länger drüber diskutiert haben und uns letztlich dafür entschieden hatten diesen Fall erst mal auszuschließen. Aktuell ist es so, das der hoodselector, wenn er keine geo Position hat, nach benachbarten BSSIDs von Mesh Routern scannt und anschließend die dazu gehörige hood aus dem hoodfile holt. Wenn keine hood zu der gescannten BSSID existiert beendet sich der hoodselector und bleibt weiterhin in der hood die beim Durchlauf zuvor gesetzt wurde. Wenn wir jetzt einen Mesh-Router haben und einen VPN-Router die miteinander meshen und es wird z.B. eine neue Firmware mit neuen hoods verteilt, kann folgendes Problem auftreten. Der VPN-Router updatet vor dem MeshRouter und wechselt in eine andere neue Hood. Der Mesh-Router wäre somit offline und würde kein Firmware Image bekommen. Nun kommt ein Lösungsvorschlag den ich in einer früheren Version des Hoodselectors schon einmal implementiert hatte. Wenn der Hoodselector keine geo Position hat, scannt er nach benachbarten BSSIDs von Mesh Routern um anschließend die dazu gehörige hood aus dem hoodfile zu holt. Wenn keine hood zu der gescannten BSSID existiert setzt der Router die gescannte BSSID mit der default Hood. Anschließend beendet sich der hoodselector. Problem hierbei ist das zwei Hoods über Layer2 verbunden werden könnten. Was ein wahrscheinlichen Ausfall beider betroffenen Hoods zur folge hätte. Mein vorchlag hier wäre also wenn eine gescannte BSSID gesetzt wird, wird fastd abgeschaltet. Somit kann der Router nur Meshen. Im nächsten Durchlauf würde der hoodselector dann versuchen eine geoposition zu beziehen. Ist das nicht erfolgreich so würde der Router prüfen ob Batman-adv GWs in Reichweite sind. Ist das der Fall beendet sich der hoodselechtor. Ist es nicht der Fall. So würde der Router wieder in den scann Vorgang gehen. Solange bis er Batman-adv GWs findet oder es keine anderen BSSIDs die unterschiedlich zu eigenen sind gibt. Kann der Hoodselector eine Geoposition ermitteln, so setzt der Hoodselector wieder die andere Hood und BSSID, die er über die Geoposition bezogen hatte. Die Folge wäre eine Trennung zum Restlichen Netz. Auch hier hatte ich schon eine mögliche Lösung implementiert. Das wenn der Router eine Hood via Position hat, der Hoodselector prüfen soll ob er Batman-adv GWs sieht. Wenn ja soll er die hood ganz normal setzen. Wenn der hoodselector keine GWs findet soll die o.g. scannroutine einsetzen. package repo: git diff edbba3be529c0d31c0f529cbaebca6e9edff01cc 58234d27a07fa72f59c7add49da2d02cae0483bc An dieser stell bin ich mir noch nicht ganz sicher denn es würde wenn ich mich logisch nicht irre eine loop entstehen das. Der Router eine bssid des nachbar Routers setzen würde mit abgeschalteten fastd. Im nächsten Durchlauf hätte der Router ja eine batman-adv GWs und würde somit wieder eine bestehende hood aus seinen hoodfile entnehmen. Dieses Phänomen würde somit immer wieder wechselnd eintreten. Eine Elegante Lösung ist mit noch nicht eingefallen. Evtl. hat jemand von euch eine mögliche Lösung die ich noch nicht gesehen hab. Schönen Gruß Tarek

8 23

git commits reverted
by Jan-Tarek Butt 08 Apr '16

08 Apr '16

Hi, @Johannes: Ich habe gerade den commit 8c373f9987036f0fd5e024254a0539ceb3109618 rückgängig gemacht da dieser ein falschen File Format Besitz. Die Datei wurde wohl in dos Format abgespeichert. dos nutzt die Endung CRLF anstatt nur LF für endlines. Magst du den commit noch mal korrigieren ? vg Tarek

1 0