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

Tobias Klaus tk+ff at meskal.net
Do Jul 30 17:37:02 CEST 2015


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&router_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&sea
> >> 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




Mehr Informationen über die Mailingliste franken-dev