Hallo fragstone,
Leider ist dem nicht so.
Ich habe auch auf einem Rechner eine Adresse aus dem Bereich bekommen, der zum Zeitpunkt der Einrichtung des Router überhaupt nicht eingeschaltet war (mitsamt nachgelagertem switch!)
Und ich kann immer noch nicht die IPv6 des Routers pingen.
Ich hab einen gefangen!
Hab mal Wireshark angeworfen und nach Router Advertisements gefilter. Habe dabei tatsächlich einen vom TP-Link empfangen! Und das auf der falschen Schnittstelle!
Wie kann man Wireshark-Output am besten hier rein kopieren?
Und wenn wirklich die fritzbox redistributed?
Der freifunk router kann das im originalzustand rein technisch schon nicht…
Im Zweifelsfall würde ich den noch einmal Flashen. INCL Löschen aller Einstellungen.
Ich habe hier auch schon komische dinge erlebt.
Gruß
Thomas
Mach nen pastebin
Und zeig mal die gesamte ‚uci show‘ des Routers bitte
Aber wenn das config foo im Router wäre müsstest du noch vor der public v6 die ula bekommen und die hast du nicht…
Das ist echt total strange
Aaaalsoooo:
unter meinem eigentlich Benutzer darf ich nicht weiter Posten. Aber kann mir dafür ohne Probleme einen neuen Account klicken o_O
Ja, die Fritzbox announced wirklich das falsche Prefix, obwohl ich eigenltich eingestellt habe, dass sie keine fremden Prefixe übernehmen soll. Werde die gleich mal neu starten, vielleicht kann ich ihr es damit wieder abgewöhnen.
Ist doch geil, also war die fritzbox der Übeltäter, hatte Thomas recht.
Hauptsache es ist nun gelöst.
Schade dass dein router keine wlan-Mesh-Verbindung zu dem anderen hin bekommt.
So.
das mit den Advertisements habe ich gelöst. Nach einem Neustart der Fritzbox announced sie das FF-Präfix nicht mehr.
Aber ein Routing-Problem habe ich trotzdem noch. Ich kann aus meinem internen Netzwerk nicht die IPv6 des Freifunk-Routers pingen.
Im Moment steht der Router auch noch auf meinem Schreibtisch. Überlege schon, wie ich ihn oder seine Antenne wetterdicht aufs Fensterbrett bekomme, damit er auch meshen kann. 
Und ausserdem überlege, ich, welche Nachbarn ich am besten noch von Freifunk überzeugen kann 
Versuch doch mal auf http://[2a02:f98:0:26:223:cdff:fe19:1132]/cgi-bin/status zuzugreifen
Ich kann von hier ganz bequem drauf zugreifen.
Zumindest wenn FF-DO-UNION11 noch aktuell ist?
Wenn dem so ist, dann hast du ein Routing/FW Problem auf der Fritzbox.
Da du ins Internet musst um darauf zuzugreifen.
Gruß
Thomas
Hi,
Union01 ist meiner, hab ich auf Bitten einer befreundeten WG dort untergebracht. Deckt die U Heinrichstraße Richtung Dorstfeld und die beiden Döner/Kiosk problemlos ab, aber an der U Richtung Innenstadt ists schon zu schwach.
Zum meshen leider noch 'n Stück zu weit entfernt…
Du hast aber nicht zufällig (vorher) die Option „Mesh via LAN“ aktiviert, dass es da noch ein „Nachecho“ gab?
Hi,
nachdem ich das nun noch einmal etwas länger beobachtet habe:
Zum einen scheint das ein Problem meiner Fritzbox zu sein, die fremde Präfixe announced, obwohl ich dies eigentlich im Menü abgeschaltet habe.
Zum anderen habe ich den TP-Link im Verdacht, dass er sein Prefix schon announced, bevor der Switch richtig konfiguriert ist. Gestern Abend habe ich Ihn nochmal neu gebootet und prompt hat er wieder ein fremdes Prefix announced. Und durch den (wahrscheinlichen) Bug in der Fritzbox haben es dann wieder alle Rechner mitbekommen.
Heute Morgen hatte sich dann alles wieder beruhigt.
Mesh via WAN/LAN habe ich übrigens nicht aktiviert.
OT: Gibt es eigentlich irgendwo eine Liste der Pakete oder eine Anleitung, wie diese konfiguriert werden müssen für FF Ruhrgebiet auf (stock) OpenWRT? Habe hier noch 2 Foneras rumfliegen, die zwar dann nicht per VPN routen sollen, aber zumindest das Mesh erweitern könnten.
Ich habe hier das gleiche Problem:
ip addr show br-wan
inet6 2a02:f98:0:26:e894:f6ff:fe69:1aa5/64 scope global deprecated dynamic valid_lft 6246sec preferred_lft 0sec
An Laptop kommt dann folgendes an:
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qlen 1000
inet6 2a02:f98:0:26:8e70:5aff:fe8e:bd68/64 scope global deprecated dynamic
valid_lft 7131sec preferred_lft 0sec
Ich glaube, dass ist alles so nicht richtig. Und wenn man das fastd via ipv6 machen will, fehlen dann auch ein paar routen, denn die müssen ja über br-wan erreichbar sein. Liege ich falsch?
Du brauchst natürlich erstmal im LAN (also auf WAN Seite für den Gluon Router) eine funktionierende RA und DHCPv6 Config, um IP Block zu announcen, DNS zu setzen etc.
Ich denke das ist bei mir auch alles richtig. Was ich nicht im Netz sehen wollte ist ein ICMPv6 vom TypRouter Advertisement mit einem Freifunk-Prefix.
Damit ist aus meinem Heimnetz das FF-Netz nicht mehr erreichbar, da der Freifunk-Router das Paket auf dem br-wan auch nicht entgegennimmt.
Wo kann/soll ich das Paket hochladen?
Mein Problem damals war auf einem WR1043nd, lösen konnte ich es letztenendes nicht. Ich hab mir zusammengereimt, dass der Switch des 1043 ein Problem beim booten hat und die VLANs des Switches erst sehr spät im Bootprozess gesetzt werden. Dadurch ist das Netzwerk nicht geteilt und der Router announced nicht nur in seinem LAN, sondern auch im (noch geswitchten) WAN (also mein LAN) fleißig sein Prefix.
Ich habe ihn dann durch einen 841 ersetzt, womit das erstmal funktionierte. Aber neulich habe ich auf einem anderen Rechner wieder eine Freifunk-IPv6 gesehen. Allerdings bin ich dem dann nicht mehr weiter nachgegangen, vermute aber, dass das seit einem der letzten Firmware-updates der Fall ist.
Ich werde wohl den Freifunk-Router aus meinem Netz nehmen und ins Gast-LAN sperren. Das sehe ich momentan als einzige zuverlässige Möglichkeit, die RAs zu unterbinden.
Da das Thema dort
nochmal aufkam:
Es scheint also immer noch aufzutreten bei einigen Plasteroutern.
Meine Vermutung ist, dass dort in der Boot-Phase des OpenWRT die Router-Advertisements loslaufen auf dem Node bevor der Switch vollständig (richtig) konfiguriert ist. Und somit RAs vom Gluon kurzzeitig auch übers WAN-Interface abgesetzt werden.
Ja, das ist ein bekanntes Problem, dem verschiedene Hersteller auf verschiedene Weisen begegnen.
Als ich damals auf dem WD My Net N750 OpenWrt portiert habe stand ich vor genau dem Problem, dass im Bootloader der Switch erstmal hart, Port für Port, deaktiviert wird. Damit konnte dann der Treiber für den Switch nicht mehr die automatische Erkennung der einzelnen PHYs sowie des Switch Chips auf dem MDIO Bus betreiben, da der Port auf dem das laufen sollte ja „down“ war.
Führte in Folge dann zu drei patches:
https://dev.openwrt.org/changeset/39126
https://dev.openwrt.org/changeset/39127
https://dev.openwrt.org/changeset/39128
TP-Link hatte den Bootloader des 1043v1 damals auf ähnliche Weise verbastelt.
Das Problem von leckenden Switches ist insbesondere auch dann blöd, wenn der Router (gerne auch mit Stock-Firmware) direkt an einem Kabelmodem hängt und sich der am Switch hängende Client leider zuerst das DHCP Lease vom Kabelnetzbetreiber abholt. Dann ist bis zum nächsten Reboot des Modems nämlich erstmal nur die MAC des Clients für DHCP Requests zugelassen. Führt zu einem Teufelskreis sobald dann der Router seine VLANs aufschaltet, den Client vom Kabelmodem abtrennt, aber letztendlich selbst nie online gehen kann, bis das Modem resettet wird.
Dem Problem wird auf Geräten mit kaputter VLAN basierter Trennung inzwischen unter OpenWrt so beigekommen, dass tlw. entsprechende Switch Deaktivierungsprozeduren in den Kernel LZMA Loader eingebaut werden, sodass der Switch in der Regel in den paar Millisekunden nachdem er durch den Bootloader initialisiert wurde direkt wieder deaktiviert wird, noch bevor der Kernel überhaupt geladen wird.
Das Problem kann zum einen am verwendeten Switch Chip liegen - es gibt durchaus Modelle, die ohne korrekte Initialisierung munter Store-and-Forward machen - oder aber der Hersteller initialisiert den Switch im Bootloader falsch (um z.B. TFTP Recovery zu machen) indem er sich bei der Initialisierung nicht richtig um die Trennung von WAN und LAN PHYs kümmert. Gibt bestimmt noch andere Gründe, die ich jetzt aber nicht alle en detail kenne.
d.h. es ist
a) routermodell-abhänig
b) kann sinnvoll nur upstream in Openwrt (und dort im uboot?) gefixed werden?