[Fli4l_dev] Tarball und OPT_IGMP

B. Sprenger b.sprenger at sprenger-ffm.de
Mo Jun 30 19:14:18 CEST 2014


Hallo Christoph,

also
ip route get 193.158.34.0
ergibt:
193.158.34.0 dev eth1.8  src 93.227.44.174
     cache

Du schriebst:
 >Das sollte dann etwas liefern wie
 >193.158.34.0 via <dein IPTV-Gateway> dev eth1.8 src <deine IPTV-IP>
Die Ausgabe sieht aber doch etwas anders aus.
Muss ich vielleicht irgendwie dem igmp-Proxy die IP des Mediareceivers 
mitteilen?



Am 30.06.2014 08:39, schrieb Christoph Schulz:
> B. Sprenger wrote:
>
>> IGMP_PROXY_ALT_N='3'
>> IGMP_PROXY_ALT_NET_1='239.35.0.0/16'	# IPTV streams
>> IGMP_PROXY_ALT_NET_2='217.0.119.0/24'	# Required for T-Home
>> IGMP_PROXY_ALT_NET_3='193.158.34.0/23'	# Required T-Home
>
> Das scheinen mir zu wenige Netze zu sein. Gemäß [1] und [2] braucht man
> noch:
>
> 193.158.137.14/32
> 87.140.255.0/25
> 87.141.128.0/17
> 87.141.64.0/18
> 217.6.164.45/32
> 217.6.164.48/29
> 217.6.167.128/26
> 217.6.167.160/27
> 212.184.168.0/24
> 217.245.0.0/18

Okay kann ich ausprobieren, aber heute und morgen bin ich nicht vor Ort.
Ich werde es am Mittwoch testen.
Aber warum funktioniert es dann mit einer älteren Version von fli4l mit 
nur drei Routen?


>
> [1] https://forum.pfsense.org/index.php?topic=72200.5;wap2
> [2] https://www.astaro.org/local-language-forums/german-forum/34579-t-online-iptv-entertain-astaro-v8.html
>


> Allerdings ist mir der Sinn dieser ganzen Aufzählungen nicht klar. Wenn man
> es vernünftig machte (!), dann müsste man diese ganzen Routen aus den
> Informationen extrahieren, die der DHCP-Client bekommt, und igmpproxy
> entsprechend konfigurieren. So ist das doch ein Krampf, insbesondere weil
> jeder (vermutlich je nach Einsatzort) andere Routen installieren muss. Ich
> tippe mal auf "static_routes" (DHCP-Option 33) und/oder
> "classless_static_routes" (DHCP-Option 121); vermutlich ist es die zweite
> Option, weil die erste keine Netzmaske mitliefert. Wenn du mal in
> opt/etc/dhcpcd.sh hinter Zeile 35 mal
>
> eval local static_routes="\$${type}_static_routes"
> eval local classless_static_routes="\$${type}_class_static_routes"
> echo "static_routes=$static_routes" >> /tmp/dhcp-routes.log
> echo "classless_static_routes=$classless_static_routes" >> /tmp/dhcp-
> routes.log
>
> einfügen, deinen fli4l aktualisieren und damit neu booten könntest, könnte
> ich sehen, ob das die richtigen, gefüllten DHCP-Felder sind. Momentan
> ignoriert das dhcp_client-Paket nämlich solche Routen, aber das kann man ja
> ändern bzw. besser mit igmpproxy verzahnen.

In [3] habe ich gelesen, dass die Telekom wohl genau das nicht macht.
Ich habe die Änderungen vorgenommen und neu gebootet.
Die beiden Dateien sind jedoch leer, bis auf die Schlüsselworte 
"static_routes=" und "classless_static_routes="

[3] http://www.onlinekosten.de/forum/showthread.php?t=116415&page=39

>
> Ansonsten würde ich auch mal schauen, ob vom igmpproxy-Paket Firewall-Regeln
> für IGMP installiert werden:
>
> iptables -S INPUT | grep igmp
Die Rückgabe dieses Befehls ist [leer]

So wie es auch Roland (im nächsten Beitrag) bereits vermutet hat.

LG
Boris





Mehr Informationen über die Mailingliste Fli4l_dev