[Freifunk Franken] 1*FF + 1*WPA2/privat auf einem Router (Former: Beitritt in Erlangen Bruck)

[Tobias Klaus]

Hallo,

das hier sollte auch wieder gehen:
https://netmon.freifunk-franken.de/api/rest/router/810

Bin gespannt, was jetzt nicht mehr geht... :-)


Am Donnerstag, 30. Juli 2015, 17:37:02 schrieb Tobias Klaus:
> Hallo Günther,
> 
> Am Donnerstag, 30. Juli 2015, 17:25:50 schrieb Guenther Schmitz:
> > hi Tobias,
> > dass der folgende Aufruf jetzt nicht mehr funktioniert ist dir bekannt?
> > 
> > https://netmon.freifunk-franken.de/api/rest/router/810
> > 
> > Ich wollte als Workaround die api.php aufrufen, jedoch kommt auch hier
> 
> > ein Fehler "Data incomplete" wenn ich folgende URL aufrufe:
> Nein, aber jetzt weiß ich woher die php-warnings kommen, die seit meinem
> "Fix" auftreten.
> 
> > https://netmon.freifunk-franken.de/api.php?rquest=router&router_id=810
> 
> Da die rewrite-rule unter api/rest/ liegt ist der korrekte Aufruf:
> https://netmon.freifunk-franken.de/api/rest/router/api.php?rquest=router&rou
> ter_id=810
> 
> Ich hoffe das hilft erstmal weiter. Der direkte Aufruf scheint eh der
> robustere zu sein und bei Gelegenheit würde ich auch den KeyXchange dahin
> patchen.
> 
> Wenn ich später dazukomme werde ich trotzdem mal versuchen die das wieder
> hinzukriegen. Bis dahin hoffe ich reicht dir der obige workaround.
> 
> Danke fürs Bescheid sagen.
> 
> Grüße
> Tobias
> 
> > Grüße
> > Guenther
> > 
> > On 07/30/2015 02:31 PM, Tobias Klaus wrote:
> > > Hallo Tom,
> > > 
> > > Am Mittwoch, 29. Juli 2015, 16:07:53 schrieb Tom Green:
> > >> Also es ist ein router (aktuell: blaufrosch 68:72:51:26:90:44
> > >> <https://netmon.freifunk-franken.de//search.php?search_range=mac_addr&s
> > >> ea
> > >> rch _string=68:72:51:26:90:44>) allein, der die Probleme verursacht.
> > >> Man
> > >> kann problemlos 2 FF Router über die selber IP ans VPN anbinden, aber
> > >> sobald der blaufrosch
> > >> dazukommt, gibt es Ärger. Laut Karte ist und war in der richtigen Hood
> > >> (Fürth) und weit genug von andern Hoods entfernt um sich da nicht zu
> > >> vermaschen.
> > > 
> > > Da ich genau am selben Tag die gleiche Erfahrung gemacht habe, habe ich
> > > mich mal auf die Suche nach dem Grund gemacht und einen ekligen Bug in
> > > der REST api des netmons gefunden, mit der der Standort eines Routers im
> > > keyXchange gefunden wird.
> > > 
> > > 
> > > Bisher sahen die Weiterleitungsregeln für die api, wenn man wie der
> > > keyXchange>
> > > 
> > > einfach nur router/$suchstring aufruft so aus:
> > >          ###############
> > >          # ROUTER      #
> > >          ###############
> > >          # get router by router_id (api/rest/router/router_id)
> > >          RewriteRule ^router/([0-9]+)/?$
> > >          api.php?rquest=router&router_id=$1 [QSA,L]
> > >          # get router by mac (api/rest/router/mac)
> > >          RewriteRule ^router/([a-fA-F0-9]{12})/?$
> > >          api.php?rquest=router&mac=$1 [QSA,L] # get router by hostname
> > >          (api/rest/router/hostname)
> > >          RewriteRule
> > >          ^router/(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]{0,61}[a-zA-Z0-9]
> > >          )
> > >          (\.([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]{0,61}[a-zA-Z0-9]))*)/?
> > >          $
> > >          api.php?rquest=router&hostname=$1 [QSA,L]>
> > > 
> > > Problem damit war, dass eine mac Addresse ohne Buchstaben als router_id
> > > interpretiert und die Anfrage entsprechend weitergeleitet wurde.
> > > 
> > > Ich habe die Zeilen mal vertauscht, das sollte uns etwas Luft geben, bis
> > > unsere router_ids 12-stellig werden. Bis dahin sollten wir da aber
> > > vielleicht eine substanziellere Lösung gefunden haben.
> > > 
> > > Kannst du das bitte nochmal ausprobieren? Ich werde nicht so schnell an
> > > den
> > > entsprechenden Router kommen.
> > > 
> > >> Neu flashen, im Netmon löschen und neu im Netmon deklarieren hat nichts
> > >> gebracht: Die selber Fehlerproblematik.  Sehr mysteriös das Ganze.
> > >> 
> > >> Ansonsten klappt das mit dem privaten Wifi, wenn der Router am WAN
> > >> hängt, ganz gut. Bei Zeiten kann ich gerne den aktuellen Stand
> > >> dokumentieren.
> > >> 
> > >> Vielleicht geht es ja trotzdem auch irgendwie auch mit FF Routern, die
> > >> nicht übers WAN sondern über Batman eingebunden sind.
> > >> 
> > >> Ich bau jetzt den Altstand zurück.
> > >> 
> > >> P.S.:
> > >> Weiß jemand, wieso auf der FFF keine Openwrt Paketverwaltung opkg ist?
> > > 
> > > Das hat mehrere Gründe. Einer davon ist, dass wir damit Speicherplatz
> > > auf
> > > den kleineren Geräten sparen. Ein zweiter ist, dass wir momentan noch
> > > vieles am Openwrt-Packet-System vorbei verwalten und wir deshalb nie
> > > garantieren können, dass sich zusätzliche Pakete mit unseren beißen.
> > > 
> > > Falls du zusätzliche Pakete benötigst, bietet es sich sowieso an, die
> > > firmware selber zu bauen und das gleich "fest" mit reinzupacken. Das
> > > spart enorm Speicherplatz. Siehe:
> > > http://wiki.openwrt.org/doc/techref/filesystems
> > > Außerdem brauchen wir für das nächste Firmware-Release eh beta-Tester
> > > ;-)
> > > 
> > > 
> > > Grüße
> > > Tobias