rt6_redirect: source isn't a valid nexthop for redirect target

Ich habe zu dieser Meldung im Logfile mal ein neues Thema aufgemacht.

Dieser Post wurde abgetrennt.

Da kann ich auch mit dienen. Kommt jede Stunde

bei mir kommt es recht unregelmäßig, aber seltsamerweise abends 20-23 Uhr sehr (!) gehäuft.

Siehe hier.

Hat jemand was im Netz verändert?
Die letzte Meldung habe ich Nov 23 14:27:23 gesehen.

Derzeit (21:14) ist es sehr still im Log. Sonst gab es zu dieser Zeit gut ein Dutzend dieser Meldungen pro Stunde.

@Reka das ist eine gute Frage. Meine Router krachen auch nicht mehr … einer ist sogar beireits 27h online :smiley:

Egal wer was gemacht hat … danke :smiley:

Gruß
THomas

seit heute, 25.11. um genau 19:00:14 sind die Meldungen wieder zu Hauf da:

Nov 25 19:00:14 ff-kk-reka kern.debug kernel: [426804.200000] rt6_redirect: source isn't a valid nexthop for redirect target

30-40 Stück pro Stunde

hat jemand um 19:00 etwas verändert?

Spannend wäre es zu wissen, ob es sich nun nach Umstellung der supernodes nochmal verändert hat.

Ich hatte eine Filterregel für ipv6 auf alle Server genommen, die auch in den anderen Domänen läuft, eventuell wurde es deshalb temporär ein bisschen weniger…

Das Verhalten ist immer noch zu sehen. Ich sehe die Meldungen aber nur dann, wenn ich mich über das Freifunk-Netz auf den Router einwähle. Greife ich über das Internet auf den Router zu, sehe ich das Verhalten nicht.

Jemand einen syslog-Server zu dem man das hinloggen kann? War kürzlich doch irgendwo hier beschrieben, wie man das via uci einrichten kann.

Das mit dem Syslog geht z.B. so:

system.@system[0].log_prefix=ffwaf-psi8
system.@system[0].log_ip=[2a02:f98:0:26:xxxx:xxx:xxxx:xxxx]

Ich habe beobachtet, dass ich für jeden Ping auf den Knoten eine entsprechenden Zeile im Syslog erhalte. Pinge ich die Lokal-Link Adresse sehe ich das Verhalten nicht. Pinge ich die fda0:: Adresse, sehe ich das Verhalten auch nicht.

Lustig ist auch die ttl:

64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=4 ttl=62 time=81.8 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=5 ttl=62 time=85.4 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=6 ttl=253 time=82.1 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=8 ttl=253 time=126 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=9 ttl=253 time=79.6 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=10 ttl=253 time=94.6 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=11 ttl=253 time=115 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=12 ttl=253 time=81.2 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=13 ttl=253 time=87.5 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=14 ttl=253 time=83.7 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=15 ttl=253 time=81.2 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=16 ttl=253 time=85.4 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=17 ttl=253 time=79.2 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=18 ttl=253 time=81.7 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=19 ttl=253 time=96.5 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=20 ttl=62 time=89.7 ms
64 bytes from 2a02:f98:0:26:ea94:f6ff:fe68:1aa4: icmp_seq=21 ttl=62 time=98.8 ms

Also mal 63, mal 253. Und oft bei Wechsel, sehe ich dann Paketverluste. Batman, das mal rechts und mal links-rum routet?

1 „Gefällt mir“

Ich glaube, der Fehler verschwindet, wenn man folgendes auf dem Knoten konfiguriert:

ip -6 route add 2a02:f98:0:26::/64 dev br-client

Der Eintrag wird aber, vermutlich vom dem Prozess gelöscht, der dafür verantwortlich ist, dass die IP überhaupt auf das interface drauf kommt. Welcher ipv6 Mechanismus wird hier genutzt?

1 „Gefällt mir“