TP-Link WR842

[Klops]

Hallo,

aus meiner Sicht ist das Ding noch nicht serienreif.
Wenn man Einstellungen ändert, wie z.B. Sendeleistung, dann auf "Speichern und anwenden" klickt, passiert erstmal eine Weile nichts mehr. Macht man das öfters, ist irgendwann das WEB-Interface nicht mehr erreichbar. Gleichfalls werden die Funkverbindungen immer schlechter bis irgendwann gar nichts mehr geht.
Ich habe das jetzt schoon ein paar mal durch.

[Klops]

Ich glaube, es gibt einen Zusammenhang zwischen den Schnittstellen bzw. deren behandlung und den angeschlossenen Antennen.
Mit einer Richtantenne verändern sich die LQ/NLQ-Werte der WLAN und der VPN-Verbindungen ständig.
Mit zwei Richtantennen lief das Ding mit super WLAn-Verbindung zum entfernten Node, jedoch kam ich nicht mehr auf das WEB-Interface.

Habe jetzt den guten alten Buffalo rausgeholt. Der läuft zwar stabil, sieht aber den Node (TP-Link), zu welchem ich mit dem TP-Link Empfang hatte, nicht ansatzweise (mit der gleichen Antenne).
Den TP-Link hier auf dem Schreibtisch, also in relativer Nähe, sieht er wiederum.

Da bleibt wohl noch etwas Forschungsarbeit.

[kwm]

@3dfx,

vielleicht findet sich hier eine Lösung für die Probleme. https://blog.freifunk-ol.de/2013/10/13/ ... fentlicht/

Gruß kwm

[3dfxatwork]

Ich werde da mal rein gucken, da das aber nicht um upstream openwrt drin ist, macht es das schwierig für die Firmwares vom meshkit.
Mein 842 und 741 mit den gleichen Firmwarequellen gebaut, kommunizieren ohne Probleme mit dem Buffalo. Das mit dem WLAN scheint ein Problem mit allen TP-Link mit Atheros WLAN zu sein (laut oldenburger Artikel), dass das Webinterface sich aufhängt hab ich auch schon manchmal festgestellt, aber noch keine Ursache gefunden. Ein neustart hilft immer, die alten starten ja auch mit jeder Änderung neu.

Edit: Das meißte kommt aus dem Openwrt Trunk, aber den benutze ich schon um die FW zu bauen, also bringt das nicht allzu viel. Der Wlan Watchdog ist aber interessant für Klops Problem, was ich jetzt auch hier nachvollziehen kann.

[Klops]

Hallo,

ich habe einen weiteren Fehler:

Wenn ich auf der Startseite im Menü OLSR-Routen klicke, geht das bei dem WR ohne Tunnel. Bei dem mit Tunnel - ich habe 2 Geräte - erscheint:

/usr/lib/lua/luci/dispatcher.lua:384: Failed to execute call dispatcher target for entry '/freifunk/olsr/routes'.
The called action terminated with an exception:
/usr/lib/lua/luci/controller/olsr.lua:414: attempt to index local 'jsondata4' (a nil value)
stack traceback:
[C]: in function 'assert'
/usr/lib/lua/luci/dispatcher.lua:384: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:139: in function </usr/lib/lua/luci/dispatcher.lua:138>

Befindet man sich im Administrations-Modus, kackt das Web-Interface ab bzw. hängt sich die ganze Kiste auf.
Genauso bei Klick auf "Topologie".

Man kommt dann erst nach Neustart des Routers wieder drauf, allerdings m.E. auch nur, wenn man die WAN-Verbindung abzieht.
Das mit der WAN-Verbindung ist aber noch nicht ganz sicher.

Grüße

K.

[kwm]

Das ist kein Fehler in der Firmware, sondern ein Problem mit dem Webbrowser und Cookies.

[3dfxatwork]

ah ok, so was ähnliches hab ich auch (allerdings bei einer virtuellen Maschine), da muss ich auch mal die cookies löschen.

[kwm]

@3dfx,

bist du sicher, das Botinfo bei den 741 mit dabei ist? 7-36 und 7-37 melden sich nicht in der IP-Liste im Wiki an.

[3dfxatwork]

Wenn mein Desktop-Rechner irgendwann mal wieder geht, prüfe ich das.

[Klops]

So, ich habe das nochmal ausprobiert.

Der WAN-Port hat eine IP per DHCP, nehmen wir an 192.168.5.200.

Aus meinem LAN komme ich damit auf das Web-Interface.
Klicke ich auf OLSR->Routen, schmiert das Interface ab.
Auch per WLAN, z.B. 104.62.10.12, kommt man nicht mehr drauf. Nicht mal die Hinweis-Seite, wo man die Regeln zur Kenntnis nehmen darf, funktioniert. Die Tunnel und WLAN laufen jedoch weiter.

Ein Neustart führt nicht zum Erfolg. Tunnel und WLAN laufen zwar (manchmal auch nur ein Tunnel), aber ansonsten alles wie oben beschrieben.

Erst ein Neustart ohne WAN-Verbindung führt zum Erfolg.
Steckt man WAN wieder an, werden dann die tunnel wieder aufgebaut und alles funktioniert wie es soll.

Es liegt nicht am Browser, denn ich habe mehrere ausprobiert - auch mehrere Rechner.

[3dfxatwork]

OK da hab ich eine Idee woran das liegen kann

[3dfxatwork]

Ich hab eine neue Version hochgeladen, welche das Problem mit dem Webinterface bei angeschlossenem WAN behebt und das WLAN Problem mit dem Oldenburger WLAN-Watchdog erschlägt, Konfigurationsproblem behoben.

Wan-Problem: war noch Code von mir, die statischen Routen dynamisch einzutragen, der hatte irgendwas kaputt gemacht, da das sowieso nicht funktioniert, hab ich das wieder entfernt.

WLAN-Problem: Watchdog aus Oldenburg überwacht den Log und startet neu sobald wlan Probleme erkannt werden (das konnte ich noch nicht testen, da das immer ein paar Tage dauert, bis das Problem bei mir auftritt)

Konfigurationsproblem: nach dem Ändern der IP über den Mesh-Assistenten, waren manche einträge doppelt vorhanden (ntp-server, olsr-tap-interfaces, network-tap-interfaces, firewall-tap-interfaces)

Konfiguration muss nicht unbedingt gelöscht werden, wenn es zu Problemen kommt, dann doch nochmal zurücksetzen und neu einrichten.

Zu finden sind die Firmwares im alten Ordner unter http://freifunk-halle.net/firmware/tl-wr842nd oder http://freifunk-halle.net/firmware/tl-wr741nd

[Klops]

Hab's ausprobiert.

Läuft derzeit super. M.E. deutlich schneller, Klick auf Routen bringt die Routen ohne Absturz.

Noch was für die Meckerecke:

Klick auf Topologie bringt:

Bad Gateway
The process did not produce any response

Aber das Web-Interface läuft danach noch.

Weiterhin: wenn die Kiste bootet, bekommt man erst ein oder zweimal eine Adresse am LAN zugewiesen, aber nur kurz.
Danach dann lange mal nichts, was dazu führt, dass Windows irgendwann eine default-Adresse (169.xxx) zuweist.
Am Besten funktionierts, wenn man ohne LAN-Kabel bootet, dann 3Min. wartet und dann das LAN-Kabel steckt.
Das sind aber sicherlich Dinge, die Zeit haben.

[3dfxatwork]

Danke erstmal für den Input, ich hab mitbekommen, dass die Botinfo in den Images fehlt. Das liegt an einen nicht mehr vorhandenen Paket in Openwrt, ich versuche das in den nächsten Tagen wieder zum laufen zu bringen.

[Klops]

Nach Strom weg->Strom dran hatte sich das Teil dann doch aufgehangen.

Habe jetzt mit "Konfiguration löschen" nochmal geflasht. Läuft soweit.

[Klops]

Wenn man unter Administration->Dienste->OLSR->Plugins klickt werden sofort 18 ungespeicherte Änderungen angezeigt.
Diese sind:

olsrd.cfg1c4e54=LoadPlugin
olsrd.cfg1c4e54.ignore=1
olsrd.cfg1c4e54.library=olsrd_sgwdynspeed.so.1.0.0
olsrd.cfg164e54=LoadPlugin
olsrd.cfg164e54.ignore=1
olsrd.cfg164e54.library=olsrd_dyn_gw_plain.so.0.4
olsrd.cfg184e54=LoadPlugin
olsrd.cfg184e54.ignore=1
olsrd.cfg184e54.library=olsrd_p2pd.so.0.1.0
olsrd.cfg124e54=LoadPlugin
olsrd.cfg124e54.ignore=1
olsrd.cfg124e54.library=olsrd_bmf.so.1.7.0
olsrd.cfg144e54=LoadPlugin
olsrd.cfg144e54.ignore=1
olsrd.cfg144e54.library=olsrd_dot_draw.so.0.3
olsrd.cfg1a4e54=LoadPlugin
olsrd.cfg1a4e54.ignore=1
olsrd.cfg1a4e54.library=olsrd_secure.so.0.6


Muss das so?

[3dfxatwork]

Ja das muss so, wenn luci bemerkt, dass es für olsrd plugins gibt, die nicht mit in der konfiguration stehen, werden die eingefügt, das ignore sagt, dass die plugins abgeschaltet werden.

[Klops]

So, ein neues Thema.

Ich stecke das LAN-Kabel an den WAN-Port.
Tunnel laufen stabil. WAN-Port hat interne IP 192.168.5.200.
Darüber komme ich auf das Web Interface.
Funkverbindung zu benachbarten Node liegt bei ETX=1.

Nun konfiguriere ich LAN-Schnittstelle statisch auf 192.168.5.199. DHCP für diese Schnittstelle deaktiviert.
Stecke das LAN-Kabel auf Port1 und ein Weiteres LAN-Kabel zwischen Port2 und WAN-Port.
WAN-Port kriegt per DHCP wieder die 192.168.5.200.
Tunnel laufen (auf den ersten Blick) wieder stabil.
Die Funkverbindung zum Nachbarnode liegt jetzt jedoch bei ETX=2, schwankend.

Nun baue ich rückwärts, d.h. LAN-Kabel wieder auf WAN, das zusätzliche KABEL raus.
Nun komme ich nicht mehr per 192.168.5.200 auf das Web-Interface.
Tunnel laufen nach mehrfachen Neustarts aber stabil

[kwm]

Du hast am selben Router WAN-Port und Lan1-Port verbunden? Warum?

[Klops]

Weil ich die Syslog-Daten in mein LAN schicken will.
Das funktioniert nicht über WAN.
Unabhängig davon muss das ja funktionieren, oder?

[3dfxatwork]

Das muss man möglicherweise erst in der Firewall freigeben.
Du kannst die beiden Verbinden, nur sollte die LAN und WAN Adresse aus einem anderen Adressbereich kommen, aber das bringt dir ja scheinbar nichts. Ich schlage vor nur am WAN Port anschließend und nochmal an der Firewall nachgucken, bzw. eine Regel erstellen, die das erlaubt.

[Klops]

nur sollte die LAN und WAN Adresse aus einem anderen Adressbereich kommen

warum das?

Unabhängig davon wundert mich die Beeinflussung der WLAN-verbindung durch die LAN/WAN-Anschlüsse.

Wenn man übrigens in der Schnittstellenkonfiguration was ändert, z.B. eine statische IP für LAN einträgt, erscheint eine "Eieruhr" mit der Ansage, dass die Änderungen angewandt werden.
Die geht aber niemals weg und die Kiste hängt sich erstmal auf.

[3dfxatwork]

Man sollte die Adressen nicht im Gleichen Bereich nutzen, da dann eine Firewall ad absurdum wird, weiterhin kann die Firewall nicht zwischen lan und wan unterscheiden und es kann zu unvorhersagbaren Problemen kommen.
Weiterhin kann das Routing durcheinander kommen und auch antwortet der Router dann vielleicht mit der falschen Adresse, was der Client dann nicht verarbeiten kann. Zu guter letzt kann es zu Schleifen kommen, sodass Pakete kreisen und nie ans Ziel kommen, da auf beiden Seiten des Switches die IP als bekannt vorkommt, das kann die CPU-Last erhöhen und somit nicht mehr genug Rechenleistung für wlan und olsr übrig bleibt, es werden pakete verworfen und schon wird die Verbindung schlechter.
Verbinde den Router nur über LAN oder WAN mit deinem Netzwerk, nicht beides.

[Klops]

Im Prinzip brauche ich ja auch keine Firewall zwischen WAN und LAN, da ja der Tunnel auf einer virtuellen Schnittstelle in der Kiste beginnt und auf meinem privaten Router ja auch beide Schnittstellen in einem Netz laufen.
Ich brauche also m.E. ja nur eine Firewall zwischen meinem privaten IP-Bereich und dem FF-Netz/Tunnel?

Es ist aber vermutlich so, dass die Firewall da derzeit durcheinanderkommt, weil da LAN und WAN getrennt werden sollen.

[kwm]

Man (ich) kann die Router auch kaputt konfigurieren. Was genau willst du eigentlich machen.

[Klops]

Eigentlich nur Lernen.

Der Ansatz war, die Logs in mein privates Netz zu speichern.
Da das nur über LAN geht dachte ich mir, o.k., die Schnittstellen haben unterschiedliche MAC, also kann ich zwei Adressen vergeben.
Dass die FW dann mit einem Adressbereich für eigentlich getrennte Netze umgehen muss, habe ich nicht bedacht.

[kwm]

Eigentlich nur Lernen.

OK, mache ich auch ...

... ich komme von meinem Router(A) auch auf das Netz des FF-Routers. Du musst dafür ein bisschen was in die Routingtabelle deines Routers(A) schreiben.
Umgekehrt geht das auch, wenn in den statischen Routen auf dem FF-Router eingetragen ist, wo sich NETZ abc befindet, kann dieses auch geroutet werden.

[Klops]

So, habe jetzt die LAN-Strippe alleinig auf dem LAN-Port.
LAN-Port auf DHCP-Client gestellt.
Nicht an der firewall rumgefummelt.

Zu meinem Erstaunen haben sich die Tunnel aufgebaut und funktionieren mit atemberaubender Geschwindigkeit.
Zum Vergleich: bisher 0,5 MBit/s, jetzt 4,5 MBit/s!

Nun könnt ich nochmal auf WAN-Port stecken um die Gegenprobe zu machen, ist aber schon zu dunkel.

[kwm]

Ups, hast du mal geschaut, was jetzt dein Gateway ist.
Du gehst jetzt über die 192.168.3.1 ins Internet. Das ist nicht Sinn der Sache. Die Firewall erlaubt der Schnittstell Lan am FF-Router fast alles. Denn diese gehört zu deinem privaten Netz. Für den FF-Router gehört jetzt das Internet zum privaten Netz. Auch wenn die VPN-Tunnel zu den Gatwayservern beide an deinem Router aufgebaut sind, Datenverkehr ins und aus dem Internet läuft jetzt über 192.168.3.1.

[Klops]

Jetzt nicht mehr