[Fli4l_dev] Tarball und OPT_IGMP

[Stephan Sanders]

Hallo Florian,

Am 01.07.2014 09:11, schrieb Florian Wolters:
> Guten Morgen zusammen,
> 
>>  Was ich aber immer noch nicht verstehe ist die Tatsache, dass diese o.g. 
>>  Route zum Netz 193.58.34.0/23 gesetzt sein muss, damit alles funktioniert, 
>>  diese Route aber nicht per DHCP übermittelt wird... Was soll der Quatsch?
> 
> Über genau dieses Problem war ich auch gestolpert. Ich kann mir nicht
> vorstellen, dass die ganzen Speedport Büxen eine solche Route
> hardwaremäßig eingebaut haben - zumal sich je nach Region offenbar auch
> das Gateway ändert.
> 

Das Problem ist ein Sicherheitsfeature welches "vernünftige"
Betriebssysteme haben. URPF  Unicast Reverse Path Forwarding.
[1]. Ist Standardmäßig unter Linux aktiviert und führt dazu, dass nur
Pakete angenommen werden, zu denen auch eine Rückroute existiert. Das
ganze wird gegen IP Spoofing angewandt.
In dem Problem von letztem Juni funktionierte auf einigen Linuxroutern
auch der Workaround, dass man URPF deaktivert:
echo 0 > /proc/sys/net/ipv4/conf/<vlan8-interface>/rp_filter

Das funktionierte auf meinem fli4l damals leider nicht.

Vor Juni2013 bekam man die Route für das 193er Netz per DHCP. Dadurch
funktionierte alles. Bei der Änderung im Juni wurde diese Route
entfernt. Bei allen Geräten mit korrekten URPF lief dann kein Multicast
mehr. Ergo: Speedports haben kein URPF implementiert!

Ich habe das bei meinen "Kollegen" auch angemeckert. ;-)


> Ich habe die Route tatsächlich manuell per 
> 
> IP_ROUTE_x='193.158.34.0/23 84.164.255.254'
> 
> konfiguriert. Damit läuft es bei mir. Ich hatte dazu in dem bereits
> zitierten Thread [1] mal was geschrieben.
> 

Richtig! Dadurch hat dann der Router für diese IPs eine Rückroute und
akzeptiert die Pakete.

Viele Grüße
Stephan

[1] http://en.wikipedia.org/wiki/Reverse_path_forwarding