April 2016 - Dev - Freifunk Nordwest

Lösung des Hood vs. Kabelmesh Problems
by Simon Kurka 19 Jul '16

19 Jul '16

Hallöle, mir kam gerade ein Gedanke, der uns evtl. relativ einfach beim Problem des Kabelmeshes in der Hoodauswahl hilft. Ich habe es noch nicht zu Ende gedacht!! Stichwort VLAN. Wie wäre es, wenn wir jeder Hood eine VLAN ID zuweisen, die im Kabelmesh verwendet wird? Es wäre auf jeden Fall sichergestellt, dass Router in unterschiedlichen Hoods diese nicht per Kabelmesh verbinden. Was wir nicht unmittelbar dadurch erreichen, ist, dass ein Kabelmesh sich in der Hoodauswahl als Einheit verhält. Auf VLAN 0 könnte man Meta-Daten austauschen, entweder um a) das einheitliche Verhalten des Kabelmeshes sicherzustellen b) ein Layer 3 Routing durch das Kabelmesh zu fahren, z. B. indem die betreffenden Nodes am OSPF Verkehr teilnehmen, o. Ä. Die VLAN-Trennung könnte uns schon jetzt Sicherheit vor Verbinden zweier Hoods bringen, ohne das Kabelmesh gänzlich abzuschalten. Ansonsten, wie gesagt, nur ein kurzer Gedankenblitz, den ich sehr reizvoll finde :) -- Viele Grüße, Simon

7 10

Hood Mesh BSSID
by Johannes Rudolph 22 May '16

22 May '16

Moin, in abspreache mit Stefan bastel ich gerade am ersten Hoodfile. Ich bin über den Punkt Mesh BSSID gestolpert. Aktuell ist diese bei uns "02:CA:FF:EE:BA:BE" und für die Default Hood kann diese auch so bleiben. Kann ich einfach nach freidünken für Hoods andere BSSID vergeben, oder gibt es da vorgaben die ich noch nicht kenne`?! Ansonsten mach ich einfach: 02:CA:FF:EE:BA:BE -> Default Hood 02:CA:FF:EE:BA:B0 -> Hood Osnabrück 02:CA:FF:EE:BA:B1 -> Hood Butjardingen/Friesland/Wilhelmshaven/Wittmund und die später folgenden Hoods werden weiter hochgezählt. 02:CA:FF:EE:BA:B2 02:CA:FF:EE:BA:B3 02:CA:FF:EE:BA:B4 02:CA:FF:EE:BA:B5 02:CA:FF:EE:BA:B6 02:CA:FF:EE:BA:B7 02:CA:FF:EE:BA:B8 02:CA:FF:EE:BA:B9 Meinungen / Wünsche / Kritik / Lob / Tadel / Zustimmung / Ablehnung?! Keine Reaktion deute ich mal als Zustimmung Gruß Johannes

4 7

Dev Treffen
by Johannes Rudolph 17 May '16

17 May '16

Moin ich fand die Idee eines Fev-Treffens sehr gut ! Ich habe mal ne Doodle Umfrage erstellt zwecks Termin Findung http://doodle.com/poll/ubrxbmuhshe6y9wf Bitte eintragen wer wann Zeit und Lust hätte. Gruß Johannes

5 5

Re: [Dev] KDO offline
by Stefan 01 May '16

01 May '16

Hi, wieso sind dadurch andere Router offline? Eventuell zurückflashen? Am 30. April 2016 15:27:24 MESZ, schrieb Malte Modler via Dev <dev(a)lists.ffnw.de>: >Hi, >ich bin schuld, dass die KDO offline ist. >Die Knoten bei meiner Mutter hab ich dreister Weise auf hoodtest10 >geupdatet. > >Falls es euch stört würde ich das wohl auch wieder rückgängig machen. >Ansonsten hab ich den public-key von Tarek eingetragen, und trage auch >gern noch weitere ein. > >Knoten: >ffnw-Jaegerstrasse1-1 >ffnw-Jaegerstrasse1-2 > >LG > > > >------------------------------------------------------------------------ > >_______________________________________________ >Dev mailing list >Dev(a)lists.ffnw.de >https://lists.ffnw.de/mailman/listinfo/dev -- vg Stefan

3 3

[Fwd: Re: [gluon] Temporary use WAN-DNS]
by Bjoern Franke 29 Apr '16

29 Apr '16

Hoi, AFAIR brauchte Tim Leerhoff ja auch Zugriff auf den DNS, vielleicht ist das für ihn interessant. Grüße

1 0

[Fwd: [WLANware] [ANNOUNCE] Gluon v2016.1.4]
by Bjoern Franke 27 Apr '16

27 Apr '16

\o/ -- xmpp bjo(a)schafweide.org

1 0

Hoodselector
by Johannes Rudolph 26 Apr '16

26 Apr '16

Moin, ich habe gerstern noche eine Änderung im Hoodslector vorgenommen, damit wir auch mehre Peers pro Server haben können. War ein Problem mit dem String, habe ich behoben. https://git.nordwest.freifunk.net/ffnw-firmware/packages/commit/d899d364cf3… Desweiteren habe ich festgestellt, dass nach einenm Hood wechsel irgednwas nicht ganz rund läuft. Das was ich bisher testen konnte hat ergeben: Router neustarten dann läuft nach Hoodweschsel alles soweit. Ich denke das kann an irgendwelchen IP Settings liegen aber ich habe keine ahnung, habe mir das nicht in die Tiefe angeschaut. Gruß Johannes

7 25

Schöner Artikel über den stand von versionierungs software
by Jan-Tarek Butt 26 Apr '16

26 Apr '16

Hi, http://www.heise.de/newsticker/meldung/Free-Software-Foundation-GitHub-und-… vg :) Tarek

1 0

Firmware 0.7
by Johannes Rudolph 26 Apr '16

26 Apr '16

Moin, ich habe gerade festgestellt das es 7 Router gibt mit der Firmware 0.7 Ich denke das kommt daher das die Eigentümer eine Unterstützung für die 841 v10 nutzen wollten. Damit wir diese nicht auf der Streckelasten zukünftig, würde ich vorschlagen des Link auf dem Server umzubiegen, sodass Firmaware.ffnw.de/testing auch auf 0.8.2 zeigt. Ich denke einigen die das installiert haben war nicht bewusst was in dem fall testing bedeutet und haben es einfach gemacht Meinungen? Gruß Johannes

7 10

hoods.json
by Jan-Tarek Butt 23 Apr '16

23 Apr '16

Hi, Mag hier bitte mal jemand die hoodfiles der test hoods schreiben? :) vg Tarek

2 2

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

Firmware 0.9
by Johannes Rudolph | Freifunk Nordwest 07 Apr '16

07 Apr '16

Moin Wie ist da der Stand ? Gruß Johannes Von meinem iPhone gesendet

4 9

Puppet und Sudo
by Clemens John 07 Apr '16

07 Apr '16

Hi, ich habe git.ffnw.de zu Puppet hinzugefügt. sudo -s funktioniert auch wie erwartet. Ein normales sudo fragt mich aber nach dem Passwort, das ich natürlich nicht habe. +++ git% sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. [sudo] password for floh1111: +++ Kann sich das mal jemand ansehen? Viele Grüße Clemens

3 5

Geolocator
by Johannes Rudolph 07 Apr '16

07 Apr '16

Moin Nach dem nun der Geolocator Fix in die Firmware eingebaut ist, sind viele Router schon besser Positioniert. Nun tritt ein neues Phänomen auf. Viele Router (~70) sitzen auf den Koordinaten (Lat: 51 Lon: 9) Nach einiger Recherche, danke noch mal an die junge aus Aurich konnte ich das Problem nun nachvollziehen. Wenn man sich den Code von openwifi.su anschaut [1] sieht man zwischen Zeile 68 und 85 den Grund hierfür. Wenn keine Netzwerke gefunden worden sind, mit der jeweiligen MAC Adresse oder die gesendeten Netzwerke nicht in der openwifi.su Datenbank sind, wird über die Anfrage IP versucht die Geokoordinate zu ermitteln. (Zeile 71) Das Ergebnis kann man auch auf dem Router erkennen, da nun in der Antwort die Quality mit 0% angeben wird. Ist dieses der fall, sollten die Koordinaten zukünftig nicht mehr übernommen werden, da sie die Position der Router in keinem fall widerspiegelt. Die Zweite Methode dieses zu Verbessern, ist es die Datenbank von openwifi.su mit mehr Daten zu füttern. Dieses kann jeder machen, der ein Android Handy benutzt. Mann kann sich hier [2] die passende App runterladen. Ich werde das mal die Tage einbauen, wenn die die Quality der Antwort 0% beträgt, dass die Position dann nicht übernommen wird. Wünsche Anregungen Fragen, Ergänzungen ? Gruß Johannes [1] https://sourceforge.net/p/libwlocate/code/ci/master/tree/master/web/getpos.… [2] https://f-droid.org/repository/browse/?fdid=com.vwp.owmap

3 4

MTU detection
by Tim Leerhoff 05 Apr '16

05 Apr '16

Hallo Tarek, ich habe die MTU-detection wie besprochen als Daemon implementiert und würde sie jetzt gerne testen. Kennst Du jemanden mit einem DSLite-Anschluss und genau diesem Problem, bei dem ich mich temporär auf dem Router einloggen (ssh) könnte ? Gruß Tim

5 12

Autolocator Verbesserung
by Johannes Rudolph 03 Apr '16

03 Apr '16

Hallo zusammen, mittlerweile haben sich ein Großteil der Router auf 0.8.1 upgedatet. Darin enthalten war eine Verbesserung des Autolocators, dieser scant die WLAN’s in der Umgebung und sendet diese an das openwifi.su Projekt. Der Server versucht dann eine Position aus den empfangenen WLAN Netzen zu ermitteln. Auf Magische art und Weise sammeln sich gerade um die 15-20 Router irgendwo in Hessen. (51°?0,000'?N 009°?0,000’?E <http://flopp.net/?z=15&m=A:51:9:0:FF-IBB-CleverFit01>) Ich habe mal ein paar rausgesucht, die es betrifft: DiakoniePflegeschulenOsnabrueck4 FF-OS-PP24-Westerberg-Buedchen Loppersum-Schlossstr-Outdoor AlterBrunselHausRechts FF-IBB-CleverFit01 (http://map.ffnw.de/#!v:m;n:14cc206f8788) Vielleicht können sich die Eigentümer ja mal bei mir melden. Ich hätte gerne wenn es möglich ist Zugriff auf die Router um dieses Phänomen untersuchen zu können und in naher Zukunft dieses eventuelle Problem beheben zu können. Natürlich darf auch jeder andere, dessen Router sich dort befindet mir schreiben, ich habe einfach mal ein paar Rausgepickt aus der Masse. Vielen Dank! Gruß Johannes

3 5