View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000083Freifunk Franken FirmwareGeneralpublic2018-01-07 18:492019-10-02 12:49
ReporterChristianD Assigned Toreddog  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status resolvedResolutionfixed 
Target Version20180726-beta 
Summary0000083: Wenn Router public v6 haben, geht fc00::/7 route nicht
DescriptionWenn die Router eine public v6 haben (z.b. über den WAN Port von DSL/Kabel) und damit eine default route, geht fc00::/7 trotz eigener route auf default raus.

Ursache unbekannt, muss aber beachtet werden! Mehr Infos im Anhang
TagsNo tags attached.
Attached Files
routing.txt (3,112 bytes)    
eth1      Link encap:Ethernet  HWaddr E8:DE:27:58:7C:B7
          inet addr:192.168.2.100  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: 2003:71:af64:1221:eade:27ff:fe58:7cb7/64 Scope:Global
          inet6 addr: fe80::eade:27ff:fe58:7cb7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:519923 errors:0 dropped:2066 overruns:0 frame:0
          TX packets:294964 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:305704423 (291.5 MiB)  TX bytes:44641454 (42.5 MiB)
          Interrupt:4

br-mesh   Link encap:Ethernet  HWaddr E8:DE:27:58:7C:B6
          inet6 addr: fd43:5602:29bd:18::e8de:2758:7cb6/64 Scope:Global
          inet6 addr: fe80::eade:27ff:fe58:7cb6/64 Scope:Link
          inet6 addr: fdff::eade:27ff:fe58:7cb6/64 Scope:Global
          inet6 addr: fdff::1/64 Scope:Global
          inet6 addr: fd43:5602:29bd:18:eade:27ff:fe58:7cb6/64 Scope:Global
          inet6 addr: fdff::e8de:2758:7cb6/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3737 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3224 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:238833 (233.2 KiB)  TX bytes:1669963 (1.5 MiB)

root@FF-BTL-Ferienwohnung-Steinkohl-1-Fichtelberg:~# traceroute6 fd43:5602:29bd:
10::f81a:675a:5ffb
traceroute to fd43:5602:29bd:10::f81a:675a:5ffb (fd43:5602:29bd:10::f81a:675a:5ffb), 30 hops max, 16 byte packets
 1  p20030071AF641221D2FF98FFFE50CBDF.dip0.t-ipconnect.de (2003:71:af64:1221:d2ff:98ff:fe50:cbdf)  1.840 ms  1.200 ms  0.471 ms
 2  p20030071AF641221D2FF98FFFE50CBDF.dip0.t-ipconnect.de (2003:71:af64:1221:d2ff:98ff:fe50:cbdf)  0.498 ms !H  0.589 ms !H  0.543 ms !H

root@FF-BTL-Ferienwohnung-Steinkohl-1-Fichtelberg:~# ip -6 ro sh
2003:71:af64:1221::/64 dev eth1  proto kernel  metric 256  expires 604788sec mtu 1492 pref medium
fd43:5602:29bd:18::/64 dev br-mesh  proto kernel  metric 256  pref medium
fdff::/64 dev br-mesh  proto kernel  metric 256  pref medium
unreachable fdff::/64 dev lo  proto static  metric 2147483647  error -148 pref medium
fc00::/7 via fe80::1 dev br-mesh  metric 1024  pref medium
fe80::/64 dev br-mesh  proto kernel  metric 256  pref medium
fe80::/64 dev eth1  proto kernel  metric 256  mtu 1492 pref medium
fe80::/64 dev fffVPN  proto kernel  metric 256  pref medium
fe80::/64 dev w2ap  proto kernel  metric 256  pref medium
fe80::/64 dev w2configap  proto kernel  metric 256  pref medium
fe80::/64 dev w2mesh  proto kernel  metric 256  mtu 1528 pref medium
default via fe80::1 dev eth1  proto ra  metric 1024  expires 168sec mtu 1492 hoplimit 255 pref medium

root@FF-BTL-Ferienwohnung-Steinkohl-1-Fichtelberg:~# ip -6 ru sh
0:      from all lookup local
32766:  from all lookup main
4200000001:     from all iif lo failed_policy
4200000003:     from all iif eth1 failed_policy
4200000015:     from all iif br-mesh failed_policy
4200000031:     from all iif w2mesh failed_policy
4200000033:     from all iif w2configap failed_policy
routing.txt (3,112 bytes)   

Activities

Adrian Schmutzler

2018-01-28 13:16

manager   ~0000222

Last edited: 2018-01-28 13:17

 Nochmal ausführlich:
Mein Router sitzt in Bayreuth V2, ich will über fd43 usw. auf einen Router in FichtelbergWest zugreifen.
Dies FUNKTIONIERT dann, wenn:
- der Zielrouter ein reiner Meshrouter ist
- der Zielrouter Uplink hat, aber im Uplink-Netz nur eine IPv4 bekommt.

Dies funktioniert NICHT, wenn:
- der Zielrouter Uplink hat und im Uplink-Netz eine IPv6 bekommt.

Im letzteren Fall wird das Router des fc00::/7 über die default-Route ins Uplink-Netz versucht, was nicht funktioniert.

Als Workaround kann man IPv6 auf dem WAN-Interface (üblicherweise eth0.2) deaktivieren:
https://pw.freifunk-franken.de/patch/768/

Das Problem ist nicht immer reproduzierbar.

reddog

2018-01-28 13:53

manager   ~0000224

Last edited: 2018-01-28 13:54

 Kurze vermute:
Ich denke damit das Routing geht, _muss_ forwarding aktiviert werden:
Dazu muss aber vorher das Akzeptieren von RA auf "Overrule forwarding behaviour" gestellt werden, sonst gibts kein RA mehr:
echo 2 > /proc/sys/net/ipv6/conf/eth1/accept_ra <--- In dem Fall ist eth1 natürlich das WAN dev
Danach Forwarding an schalten:
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

Nun sollte auch das Routing auf fc00::/7 gehen.

ChristianD

2018-01-28 15:49

manager   ~0000225

Last edited: 2018-01-28 15:51

 @reddog

aber würde dann fc00::/7 überhaupt gar nicht gehen? Es geht ja solang auf den WAN keine v6 Adresse ist. Wenn auf WAN eine v6 ist, routet er fc00::/7 dort raus obwohl eigentlich die fc00::/7 wo anders hin zeigt. Für mich sieht das bisher nach einem Bug (im Kernel?) aus.

reddog

2018-01-28 16:05

manager   ~0000226

Gute Frage. Es könnte auch ein Sicherheitsfeature sein, dass lokales routing deaktiviert wird, sobald ra's da sind. Oder durch irgendetwas wird das fc00::/7 als routing gewertet, nachdem ein ra da ist und vorher nicht.
Ich denke ein wenig Recherche kann hier nicht schaden.

Zu meinem obigen Vorschlag, würde ich noch ergänzen, dass man das forwarding zwar aktiviert, aber auf dem WAN Interface selbst wieder raus nimmt. Dann sollte die 2 auf accept_ra nicht nötig sein und außerdem sollte man (sofern die Konzepte so greifen, wie ich hoffe) nicht ausversehen traffic ins Internet schieben, der da nicht hin soll.

Adrian Schmutzler

2018-01-28 16:11

manager   ~0000227

Reddog: Kannst die neuere Variante mal als Commands hier reinschreiben, sodass ich das testen kann?

rola

2018-01-30 12:00

reporter   ~0000229

Hab mir das mal angeschaut und da tauchen einige unschöne Sachen auf. Ganz Übel ist, dass sich die Router unterschiedlich verhalten.
1. Setzen von accept_ra = 1
In der sysctl.conf wird conf.all.accept_ra=1 und conf.default.accept_ra=0 gesetzt. conf.all wirkt sich aber "nur" auf vorhandene Devices aus, und conf.default auf die, die später dazukommen. Beim 841 ist das WANDEV eth0 schon da, wenn sysctl läuft -> accept_ra=1
Beim 1043 kommt das WANDEV eth0.2 später dazu also wirkt conf.default -> accept_ra=0 und damit kein ipv6 am WANDEV.
Das trifft auf alle Einstellungen in sysctl.conf zu!! Wir müssen das umbauen. Hat jemand ein tieferes Verständnis der gesetzen Keys?

2. ipv6 Routing (ganz böse)
Wenn man accept_ra aktiviert bekommt man eine v6 und die defaultroute wird gesetzt auf fe80::1 via WANDEV. Aussedem haben wir eine fc00::/7 via br-mesh. Ein 1043 tut was man erwartet und routet eine fd43:5602:.... durch die "more specific" fc00::/7.
Der 841er macht das nicht! Der nimmt immer die default durch eth0. Egal ob man die Route von Hand setzt oder über ra rein kommt. Warum der Kernel das macht --???-- Ein Bug??
Eine Lösung ist eine eigene Routingtable für die fc00::/7 mit einer entsprechenden Rule. Dann klappts auch beim 841 und es wäre auf allen Routern gleich. Die Table könnte man später auch noch für andere Dinge nutzen.
Auch hier wären ein paar Meinungen gut bevor ich nen Patch mach.

Adrian Schmutzler

2018-01-30 12:23

manager   ~0000230

Dann setzen wir einfach default und all auf die gleichen Werte und gut ist?

ChristianD

2018-01-30 12:34

manager   ~0000231

ohne jetzt ganz tief drüber nachgedacht zu haben, die Idee fc00::/7 in ne extra rt wegzusperren klingt irgendwie recht hübsch. Seh da jetzt auf die schnelle keine negativen Effekte die dadurch auftreten könnten.

rola

2018-01-30 12:40

reporter   ~0000232

Nicht gut, dann konfigurieren sich alle devices, die irgendwoher ras empfangen. Das mit dem accept_ra ist einfach ueber eine weitere Zeile in der configurenetwork zu loesen. Aber wenn man schon an die sysctl.conf geht, sollte man gleich mal aufraeumen. Da sind noch Keys drin, die es nicht mehr gibt. Und vielleicht sollte man manche auch auf default=1 setzen fuer die 1043. Aber da fehlt mir "noch" der Durchblick.

Adrian Schmutzler

2018-01-30 12:43

manager   ~0000233

Habe mir gerade mal die History der sysctl.conf angesehen:
https://github.com/FreifunkFranken/firmware/commits/master/bsp/default/root_file_system/etc/sysctl.conf

Der einzige, der da je was inhaltlich dran getan hat war reddog.

Die letzte "inhaltliche" Änderung war 2013:
https://github.com/FreifunkFranken/firmware/commit/118d7d8236d6e3dc67ae68fa41a29fe96de21ac1#diff-e442ca9025162ec51dcb665a6f9e0327

Das scheint auch die relevante Änderung gewesen zu sein. Ich frage mich, ob es nicht am einfachsten wäre, im sysctl.conf alles wieder auf =0 zu setzen und dann auch accept_ra nur selektiv für das wan-interface zu setzen. Das löst dann nur 1., aber Problem 2 ist eh davon unabhängig.

Ich versuche das mal in einem Patch zu vereinheitlichen ...

Adrian Schmutzler

2018-01-30 12:59

manager   ~0000234

So, hier ein Patch für Teil 1 als Diskussionsgrundlage:
https://pw.freifunk-franken.de/patch/770/

Das mit der Routingtabelle für Teil 2 fände ich auch interessant, du kannst gerne einen Patch oder eine Anleitung schicken, dann kann ich das hier mal auf einem meiner betroffenen Geräte testen.

rola

2018-01-30 14:17

reporter   ~0000235

Dafuer sollte das reichen: https://pw.freifunk-franken.de/patch/771/

rola

2018-02-03 02:14

reporter   ~0000239

Hat jetzt etwas gedauert, war aber auch nicht ganz einfach.
Manche Router kennen die fe80::1 vom GW via br-mesh nicht. Das sieht dann so aus:
root@rola2:~# ip -6 n
fe80::1 dev eth0 lladdr 5c:dc:96:bf:d2:4f router STALE
fe80::12fe:edff:feaf:b638 dev br-mesh lladdr 10:fe:ed:af:b6:38 router STALE
fd52:28be:4c6f:1::1 dev eth0 lladdr 5c:dc:96:bf:d2:4f router STALE
fe80::1 dev br-mesh FAILED
Darum nimmt er die Route auch nicht.

Im RFC 1256 steht, wie ein Host an diese Info ran kommt. Entweder ueber ra (Router Advertisements) oder ueber rs (Router Solicitations). Die rs werden nur kurz nach dem Hochfahren des Interfaces gesendet. Bei uns 3 mal (net.ipv6.conf.eth0.router_solicitations = 3) Und da haben manche Router noch keine Verbindung zum GW.
Danach kommt das mit den ra rein. Bei uns aber nicht, da wir das nicht announcen. Wenn man am GW die radvd.conf um die fe80::1 ergaenzt:
        AdvDefaultLifetime 0;
        AdvRASrcAddress {
                fe80::66:66:66:1;
                fe80::1;
        };
        prefix fd43:5602:29bd:16::/64 {
dann geht es!!
Sieht dann so aus:
root@rola2:~# ip -6 n
fdff::ddab:c00d:d459:e5e7 dev br-mesh lladdr 84:16:f9:0c:26:c2 REACHABLE
fe80::1 dev eth0 lladdr 5c:dc:96:bf:d2:4f router STALE
fe80::1 dev br-mesh lladdr 22:b1:dc:08:67:c0 router REACHABLE

Was noch getestet werden muss ist, was passiert, wenn mehrere GWs die fe80::1 anbieten. Sollte aber funktionieren.

rola

2018-02-03 02:28

reporter   ~0000240

Fast vergessen! Wichtig ist natuerlich auch sicher zu stellen, dass ra auf br-mesh erlaubt sind!!

reddog

2018-02-11 14:59

manager   ~0000246

Wir hatten uns aktiv gegen das akzeptieren von RA's auf dem br-mesh entschieden, da sich die Knoten dann ggfs gänzlich unterschiedlich verhalten werden.

Die Theorie, dass "fe80::1 dev br-mesh FAILED" per se Schuld ist stimmt nicht:
--- %< ---
root@ding:~# ip -6 -d n
fe80::1 dev br-mesh FAILED
[..]
root@ding:~# ip -6 -d ro
[..]
unicast fdff::/64 dev br-mesh proto kernel scope global metric 256 pref medium
[..]
unicast default via fe80::xxxx:xxxx:xxxx:xxxx dev eth1 proto ra scope global metric 1024 expires 1752sec hoplimit 64 pref medium
root@ding:~# ip -6 -d ro get fc00::1/64
unicast fc00::1 from :: via fe80::1 dev br-mesh table main proto static scope global src fd43:5602:29bd:4:xxxx:xxxx:xxxx:xxxx metric 1024 pref medium
root@ding:~# ip -6 -d n
fe80::1 dev br-mesh FAILED
[..]
--- >% ---

Sieht eher so aus, als ob durch den Fehler beim raussuchen der Route die fe80::1 nie versucht wird zu kontaktieren und deshalb der neigh auf FAILED steht. Würde die richtige Route gewählt werden, würde mit dem absenden einer Nachricht auch das FAILED verschwinden (sofern sonst keine Störung am Netz vorliegt).

Bis jetzt ist mir leider nix besseres eingefallen als forwarding auf global und auf allen Interfaces, außer dem WAN interface zu aktivieren. Zur Sicherheit bietet sich vielleicht noch an:
/sbin/iptables -P FORWARD DROP
/sbin/ip6tables -P FORWARD DROP
zu setzen. Was da aber für Nebenwirkungen für die neigh disc entstehen weiß ich nicht, immerhin wird den Nachbarn erzählt, dass wir routen können wenn wir das tun.

reddog

2018-03-03 21:37

manager   ~0000251

Fix committed to master branch.

Issue History

Date Modified Username Field Change
2018-01-07 18:49 ChristianD New Issue
2018-01-07 18:49 ChristianD File Added: routing.txt
2018-01-28 13:16 Adrian Schmutzler Note Added: 0000222
2018-01-28 13:17 Adrian Schmutzler Note Edited: 0000222
2018-01-28 13:28 reddog Category PATCHES => Freifunk Franken Firmware
2018-01-28 13:28 reddog Target Version => 20180726-beta
2018-01-28 13:53 reddog Note Added: 0000224
2018-01-28 13:54 reddog Note Edited: 0000224
2018-01-28 15:49 ChristianD Note Added: 0000225
2018-01-28 15:51 ChristianD Note Edited: 0000225
2018-01-28 16:05 reddog Note Added: 0000226
2018-01-28 16:11 Adrian Schmutzler Note Added: 0000227
2018-01-30 12:00 rola Note Added: 0000229
2018-01-30 12:23 Adrian Schmutzler Note Added: 0000230
2018-01-30 12:34 ChristianD Note Added: 0000231
2018-01-30 12:40 rola Note Added: 0000232
2018-01-30 12:43 Adrian Schmutzler Note Added: 0000233
2018-01-30 12:59 Adrian Schmutzler Note Added: 0000234
2018-01-30 14:17 rola Note Added: 0000235
2018-02-03 02:14 rola Note Added: 0000239
2018-02-03 02:28 rola Note Added: 0000240
2018-02-11 14:59 reddog Note Added: 0000246
2018-03-03 21:37 reddog Source_changeset_attached => Firmware master bd5985e9
2018-03-03 21:37 reddog Note Added: 0000251
2018-03-03 21:37 reddog Assigned To => reddog
2018-03-03 21:37 reddog Status new => resolved
2018-03-03 21:37 reddog Resolution open => fixed
2019-10-02 12:48 fbl Category Freifunk Franken Firmware => General
2019-10-02 12:48 fbl Category General => General2
2019-10-02 12:49 fbl Category General2 => General