Subject: 3.4.0 und VDSL + IP-TV Posted by rene reckschwardt on Wed

Transcription

Subject: 3.4.0 und VDSL + IP-TV
Posted by rene reckschwardt on Wed, 29 May 2013 15:59:56 GMT
View Forum Message <> Reply to Message
Hallo NG,
bei meinen Fli funktioniert seit gestern der igmp_proxy nicht mehr. Hat
T-kom irgend etwas geändert? An meinem Fli sollte sich nichts geändert
haben. Sind die neueren Versionen vom Fli besser geeignet für igmp?
Gruß ré
Subject: Re: 3.4.0 und VDSL + IP-TV
Posted by B. Sprenger on Wed, 29 May 2013 18:09:40 GMT
Am 29.05.2013 17:59, schrieb rene reckschwardt:
> Hallo NG,
>
> bei meinen Fli funktioniert seit gestern der igmp_proxy nicht mehr. Hat
> T-kom irgend etwas geändert? An meinem Fli sollte sich nichts geändert
> haben. Sind die neueren Versionen vom Fli besser geeignet für igmp?
>
> Gruß ré
>
Hallo zusammen,
ich habe auch zwei Standorte mit Ausfall.
Für einen Standort wurde bereits ein Entstörungsticket eröffnet, aber
ich vermute da wurde am Netz geschraubt und das verläuft im Sande.
Gruss Boris
Posted by rene reckschwardt on Wed, 29 May 2013 18:32:42 GMT
Hallo Boris,
> Hallo zusammen,
> ich habe auch zwei Standorte mit Ausfall.
> Für einen Standort wurde bereits ein Entstörungsticket eröffnet, aber
> ich vermute da wurde am Netz geschraubt und das verläuft im Sande.
bei mir wurde auch alles zurückgesetzt was geht aber ohne Erfolg. Der
W701V der seit Jahren im Schrank liegt funktioniert bei Anschluß ohne
Update oder irgend etwas zu ändern. Schade, hoffentlich finden wir
heraus was da geändert wurde sonst muß ich den T-kom Router benutzen.
Gruß ré
Posted by Stephan Sanders on Wed, 29 May 2013 18:40:28 GMT
Ahhhhhhh :-)
Hallo! :-)
Am 29.05.2013 20:09, schrieb B. Sprenger:
> Am 29.05.2013 17:59, schrieb rene reckschwardt:
Auch mit der aktuellen Tarball Version.
Ich habe den Speedport rangeschaltet. Dann gehts erstmal wieder.
Habe gestern die ganze Nacht versucht das zu untersuchen. Heute das
gleiche Drama. Habe erststmal ein Update auf die aktuelle Tarball
Version gemacht.
Weiß schon jemand was geändert werden muss?
Eigentlich sollte es relativ automatisch funktionieren.
a) Routen für VLAN8 werden per DHCP (Option 121) propagiert.
--> fli4l übernimmt diese:
(Eth2 = Vlan8)
cerberus 3.9.0-rev27690-testing # ip route
default dev ppp0 scope link
87.140.255.0/25 via 93.237.63.254 dev eth2 metric 205
93.237.0.0/18 dev eth2 proto kernel scope link src 93.237.25.88
metric 205
193.158.132.189 via 93.237.63.254 dev eth2 metric 205
217.0.119.37 dev ppp0 proto kernel scope link src 79.248.126.6
b) igmp-proxy:
IGMP_PROXY_ALT_N='3'
# number of IP addresses for
multicast sources
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.35.0/24' # Required T-Home
Was von den Routen oben muss ggf. noch beim igmp eingetragen werden?
Vielleicht hilft das weiter.
Noch jemand IP-TV offline? ^^ :-)
VG
Page 2 of 18 ---- Generated from
net(t)forum
Stephan
Posted by Stephan Sanders on Wed, 29 May 2013 19:32:20 GMT
Hallo,
hier noch ein paar Nachträge.
Mein Speedport ist gefritzt, so kann ich Traces auf den Schnittstellen
ziehen.
Multicastadressen sind die gleichen wie vorher.
Sourceadressen stimmen auch.
IGMP_PROXY_ALT_NET_1='239.35.0.0/16' # IPTV streams korrekt!
IGMP_PROXY_ALT_NET_2='217.0.119.0/24' #
IGMP_PROXY_ALT_NET_3='193.158.35.0/24' # Sourceadressen der Multicast
streams. Stimmt auch noch!
Aus den Supportdaten der Fritzbox: (Standort Köln)
http://fritz.box/html/support.html
mode: VDSL
cpmacconfig:normal 7,8
running (voip=0,tr069=0)
speed 51384000/10084000 token 20000
PPPoE Forward: disabled
0: name internet
0: connected vcc 0/0/PPPoE/26/UBR/0/0/dsl stay online 1 vlan 7
0: connected since 2013-05-29 20:23:19 (setup time 0 secs)
0: ip 79.XXX.XXX.XXX peer 217.0.119.37 mtu 1492
0: dns 217.0.43.33/217.0.43.17
0: acname KLNR72-se800-B2224180702329
0: route 79.XXX.XXX.XXX/32 protocol iface
0: mc to wan 224.0.1.60
0: mc to wan 239.35.100.8
0: mc to wan 239.35.20.21
0: mc to wan 239.35.20.4
0: RX bytes:11273346 pkt error:0 discard:0 filtered:27 dropped:1
0: RX pkts:14177 unicast:14177 multicast:0 broadcast:0
0: TX bytes:1859879 pkt error:0 discard:0 filtered:0 dropped:0
0: TX pkts:11989 unicast:11988 multicast:0 broadcast:1
2: name mstv
2: connected vcc 0/0/RBE/18/UBR/0/0/dsl stay online 1 vlan 8
2: connected since 2013-05-29 20:23:19 (setup time 0 secs)
2: ip 93.237.10.123 mask 255.255.192.0 gw 0.0.0.0 dhcp mtu 1500
2: dns 0.0.0.0/0.0.0.0
net(t)forum
2: route 93.237.0.0/18 protocol iface
2: route 193.158.132.189/32 via 93.237.63.254 protocol dhcp
2: mc from wan 93.237.63.254
<------ Interessant?
2: mc to wan 224.0.1.60
2: mc to wan 239.35.100.8
2: mc to wan 239.35.20.21
2: mc to wan 239.35.20.4
GGf. muss das 93.237.0.0/18 auch in den ALTNETS konfiguriert werden.
Da der Fernseher gerade benutzt wird, muss ich noch ein wenig bis zum
Umbau warten.
Viele Grüße
Stephan
Posted by d-mo on Thu, 30 May 2013 13:01:37 GMT
Hallo. Gleiches Problem. Nach 10sek. Stillstand. Habt ihr das Problem schon gelöst?
Grüße David
Posted by Stephan Sanders on Thu, 30 May 2013 13:43:08 GMT
Hallo David,
Am 30.05.2013 15:01, schrieb David:
> Habt ihr das Problem schon gelöst?
Nein. Dann würde ich es auch sofort poste.
Habe auch bei onlinekosten.de Gleichgesinnte gefunden und bei der
Telekom-hilft gepostet. Ich bin gespannt ob da was raus kommt.
Stream kommt anscheinend am fli4l an. Wird also vielleicht richtig
requested, nur falsch forgewarded. Leider habe ich keine
Vergleichsmeldungen von igmpproxy. So kann ich aktuell nicht beurteilen,
woran es liegt. Es ist nicht nur ein fli4l Problem, andere
Linuxrouter mit igmpproxy haben das gleiche Problem.
Viele Grüße
Stephan
Subject: Aw: 3.4.0 und VDSL + IP-TV
Posted by Bobohne on Thu, 30 May 2013 14:51:33 GMT
Hallo!
Auch hier ist bei drei Routern das Entertain ausgefallen.
Ich habe ebenfalls den EIndruck als würden die Multicast Pakete am Modem und an eth1
ankommen (wenn man laienhaft wie ich die Aktivitäts LEDs beurteilt) nur nicht richtig weiter
geleitet.
Wie alle anderen bin ich brennend an einer Lösung interessiert und würde auch gerne
mithelfen falls ich da etwas tun kann.
Ich habe gestern für mich und meine Eltern jeweils einen Speedport W723V als
Havarie-Lösung gekauft um vorübergehend wieder TV zu haben. Lief auch auf anhieb. Nur
sind diese Geräte in meinen Augen Schrott und die Funktionalität hängt meilenweit hinter
dem fli4l nach. Nicht mal ein ordentliches Portforwarding geht.
Ein Freund von mir wartet lieber noch eine Weile, denn ich hoffe eine Lösung ist nur eine
Frage der Zeit.
Ich habe übrigens die 93.237.0.0/18 aus Stephans Post mal bei den ALTNETS des IGMP
Proxys eingetragen und hab da auch ein wenig am Paketfilter des fli4ls herumexperimentiert.
Leider alles ohne Erfolg. Sobald die Box von Unicast zu Multicast übergeht wars das.
Die IPs der Streams haben sich doch nicht verändert. Kann man dem fli4l nicht einfach
sagen, pass auf, alles was von 239.35.0.0/16 an eth1.8 kommt knallst du so wieder an eth2
raus? Oder bin ich da zu naiv? ;)
Grüße
Michael
Posted by Stephan Sanders on Thu, 30 May 2013 18:20:49 GMT
Hallo Michael,
Am 30.05.2013 16:51, schrieb Michael Bobenstetter:
> Ich habe übrigens die 93.237.0.0/18 aus Stephans Post mal bei den
> ALTNETS des IGMP Proxys eingetragen und hab da auch ein wenig am
> Paketfilter des fli4ls herumexperimentiert. Leider alles ohne Erfolg.
Ich hatte alle Netzwerke die per DHCP propagiert werden, mal
als ALTNET definiert. Keine Änderung.
Wenn ich den Speedport dranhabe, sehe ich mit Wireshark, dass die Joins
und Leaves über beide VLANs nach draußen propagiert werden.
IGMPv3 erkennt die Fritzbox/der Speedport. War das vorher schon v3?
igmpproxy erzählt mir dagegen nur was von V2 Membershipreports. :-S:
> Sobald die Box von Unicast zu Multicast übergeht wars das.
> Die IPs der Streams haben sich doch nicht verändert. Kann man dem fli4l
net(t)forum
Die Multicaststreams haben die gleichen Sourceaddressen. (
193.158.35.0/24). Also keine Änderung.
Ich vermute Protokolländerungen???? Wurde vorher wirklich schon IGMPv3
genutzt? Habe leider keinen Mitschnitt :-(.
Aber AVM scheint ja vorher schon gewusst zu haben, was mal passiert. Ein
Speedport/Fritz W721 kann das ohne Probleme mitmachen.
Hier mal ein paar Logmeldungen für jemanden, der mehr Ahnung vom
igmpproxy hat:
32 (Id4, Time2)
32 RECV Membership query from 192.168.6.2 to 239.35.20.3
34 RECV V2 member report from 192.168.6.100 to 239.35.20.7
34 Should insert group 239.35.20.7 (from 192.168.6.100) to route
table. Vif Ix 3
34 No existing route for 239.35.20.7. Create new.
34 Found existing routes. Find insert location.
34 Inserting after route 239.35.20.3
34 Inserted route table entry for 239.35.20.7 on VIF #3
34 Joining group 239.35.20.7 upstream on IF address 93.237.25.88
34 joinMcGroup 239.35.20.7 on eth2
34
34 Current routing table (Insert Route)
34 ----------------------------------------------------34 RECV Leave message
from 192.168.6.100 to 224.0.0.2
34 Got leave message from 192.168.6.100 to 239.35.100.8. Starting last
member detection.
34 Leaving group 239.35.100.8 upstream on IF address 93.237.25.88
34 leaveMcGroup 239.35.100.8 on eth2
34 SENT Membership query from 192.168.6.2 to 239.35.100.8
34 Sent membership query from 192.168.6.2 to 239.35.100.8. Delay 10
34 Created timeout 5 (#2) - delay 2 secs
34 (Id2, Time6)
34 (Id4, Time2)
34 (Id5, Time2)
table. Vif Ix 3
34 Updated route entry for 239.35.100.8 on VIF #3
34
34 ----------------------------------------------------34 #0 Src 0.0.0.0, Dst 239.35.20.3, Age1, St I, OutVifs 0x00000008
34 #1 Src 0.0.0.0, Dst 239.35.20.7, Age2, St I, OutVifs 0x00000008
net(t)forum
table. Vif Ix 3
35
35 ----------------------------------------------------36 RECV V2 member report from 192.168.6.100 to 239.35.20.7
table. Vif Ix 3
36
36 ----------------------------------------------------40 About to call timeout 2 (#0)
41 The IGMP message was from myself. Ignoring.
41 About to call timeout 4 (#0)
41 Removing group 239.35.20.3. Died of old age.
41 Removed route entry for 239.35.20.3 from table.
41 Route is not active. No kernel updates done.
41
41 Current routing table (Remove route)
table. Vif Ix 3
net(t)forum
43
46 RECV Leave message
from 192.168.6.100 to 224.0.0.2
46 Got leave message from 192.168.6.100 to 239.35.20.7. Starting last
member detection.
46 Leaving group 239.35.20.7 upstream on IF address 93.237.25.88
46 leaveMcGroup 239.35.20.7 on eth2
46 (Id6, Time4)
46 (Id8, Time6)
46 (Id7, Time15)
50 Aging routes in table.
50
50 Current routing table (Age active routes)
table. Vif Ix 3
54 No existing route for 239.35.20.4. Create new.
54 Found existing routes. Find insert location.
54 Inserting at beginning, before route 239.35.20.7
54 Inserted route table entry for 239.35.20.4 on VIF #3
54
table. Vif Ix 3
net(t)forum
55
55 ----------------------------------------------------56 About to call timeout 8 (#0)
56 (Id9, Time10)
56 (Id7, Time5)
table. Vif Ix 3
56
56 -----------------------------------------------------
Viele Grüße
Stephan
Posted by Jens Kluge on Thu, 30 May 2013 18:42:22 GMT
Hallo Stephan,
es könnte durchaus an der verwendeten igmp Version liegen.
Am 30.05.2013 20:20, schrieb Stephan Sanders:
>
> Ich vermute Protokolländerungen???? Wurde vorher wirklich schon IGMPv3
> genutzt?
>
Der verwendete sourcecode von igmpproxy hat den Stand V2 und wurde
leider nicht upgedated.
Derzeit habe ich nur für dd-wrt Sourcen zu IGMP V3 gefunden, die so ohne
net(t)forum
weiteres (nvram) jedoch nicht passen.
http://svn.dd-wrt.com/browser/src/router/igmp-proxy?rev=8842
Vielleicht findet sich jemand der das für fli4l anpassen kann oder eine
andere Quelle für die V3 hat.
> Viele Grüße
> Stephan
>
Grüße Jens
Posted by d-mo on Thu, 30 May 2013 20:15:36 GMT
Moin nochmal.
Ich werde am WE mal meinen W722V aus dem Keller holen (hoffe das Teil geht noch...) und
den Traffic mit Wireshark untersuchen. Die Ergebinsse stelle ich euch dann umgehend zur
Verfügung.
Sollte T-Schöönchen wirklich auf V3 gewechselt haben könnte ich mit den richtigen IGMP
Quellen das ganze neu übersetzen. (hab ein funzendes FBR hier...)
Bis dahin guckt meine "Schnecke" halt nur Analog in die Röhre. :P
Schöne Grüße und packen wir's an!
David
Posted by Roland on Fri, 31 May 2013 18:50:20 GMT
Hallo,
> "Jens Kluge" schrieb im Newsbeitrag
> news:ko86ik$r81$1@vm-news.spline.inf.fu-berlin.de...
> Hallo Stephan,
> es könnte durchaus an der verwendeten igmp Version liegen.
> Am 30.05.2013 20:20, schrieb Stephan Sanders:
>>
>> Ich vermute Protokolländerungen???? Wurde vorher wirklich schon IGMPv3
>> genutzt?
>>
> Der verwendete sourcecode von igmpproxy hat den Stand V2 und wurde leider
> nicht upgedated.
> http://svn.dd-wrt.com/browser/src/router/igmp-proxy?rev=8842
net(t)forum
> Vielleicht findet sich jemand der das für fli4l anpassen kann oder eine
> andere Quelle für die V3 hat.
Quelle wäre zum Beispiel:
http://wl500g.googlecode.com/svn/!svn/bc/4526/trunk/igmpproxy/
incl. dem dort befindlichen Patch 050-igmpv3.patch
>> Viele Grüße
>> Stephan
>>
> Grüße Jens
Gruß Roland
Subject: Aw: Re: 3.4.0 und VDSL + IP-TV
Posted by Bobohne on Sat, 01 Jun 2013 13:25:37 GMT
Hallo Roland!
Vielen Dank für deine Hilfe!
Ich hab mir das mal (aus Neugier, denn ich kenn mich mit Linux kaum aus) diese Dateien mal
angesehn und hab mir auch die 050-igmpv3.patch durchgesehen. Ich verstehe natürlich
nicht was da drin alles steht nur wundere ich mich etwas bezüglich der SOURCES auf die in
der Datei verwiesen wird. Da ist unter anderem von einer igmpv3.h die Rede. Ich hab mir mal
die Dateien des igmpproxys angesehen und in dessen src-Verzeichnis fehlt diese. Ich hab
mich mal ein wenig im Netz auf die Suche gemacht aber kann sie nirgends finden.
Vielleicht versteh ich das auch alles falsch und und die patch datei beschreibt in Wahrheit
diese igmpv3.h, dann ists natürlich wurscht und es müsste nur jemand der Ahnung hat
unser geliebtes OPT patchen (wenns so einfach ist ;) ).
Grüße
Michael
Posted by rene reckschwardt on Sat, 01 Jun 2013 19:37:24 GMT
>
>
>
>
>
Hallo NG,
bei meinen Fli funktioniert seit gestern der igmp_proxy nicht mehr. Hat
T-kom irgend etwas geändert? An meinem Fli sollte sich nichts geändert
haben. Sind die neueren Versionen vom Fli besser geeignet für igmp?
der Sourcecode http://sourceforge.net/projects/igmpproxy/ hat am
25.05.13 ein Update erhalten, ich kann nur nichts finden was da geändert
wurde?
Gruß ré
Posted by Roland on Sat, 01 Jun 2013 20:00:18 GMT
Hallo Rene,
> "rene reckschwardt" schrieb im Newsbeitrag
> news:kodihk$mec$1@vm-news.spline.inf.fu-berlin.de...
>> Hallo NG,
>>
>> bei meinen Fli funktioniert seit gestern der igmp_proxy nicht mehr. Hat
>> T-kom irgend etwas geändert? An meinem Fli sollte sich nichts geändert
>> haben. Sind die neueren Versionen vom Fli besser geeignet für igmp?
> der Sourcecode http://sourceforge.net/projects/igmpproxy/ hat am 25.05.13
> ein Update erhalten, ich kann nur nichts finden was da geändert wurde?
Du kannst auch den Sourcecode von sourceforge nehmen und die Patches von
https://code.google.com/p/wl500g/source/browse/#svn%2Ftrunk%2Figmpproxy
darauf anwenden und es kommt da auch nichts anderes raus als wenn
du die dortigen files (Bei code.google.....) verwendest.
Auch sind die Files im Paket die alten.
Gruß Roland
Hallo,
> bei meinen Fli funktioniert seit gestern der igmp_proxy nicht mehr. Hat
> T-kom irgend etwas geändert? An meinem Fli sollte sich nichts geändert
> haben. Sind die neueren Versionen vom Fli besser geeignet für igmp?
hat vielleicht jemand vom Zeitpunkt vor dem Ausfall ein Syslog-Protokoll,
in dem Hinweise/Informationen zur funktionierenden Übertragung zu
finden sind?
Vielleicht kann über dieses eine Information herausgezogen werden, was
sich jetzt geändert hat.
Gruß Roland
Posted by Stephan Sanders on Sat, 01 Jun 2013 20:59:03 GMT
Hallo,
Ich gebe hier mal den Stand der letzten beiden Tage wieder.
net(t)forum
Jetzt gebe ich mal kurz den Untersuchungsstand der letzten beiden Tage
wieder.
Für den fli4l wird auch igmpproxy in der Version0.1 verwendet. Bisher
ungepatcht.
Eine Änderung ist der Wechsel auf igmpv3.
Weitere Änderungen sind ggf. noch unbekannt, die die Telekom gemacht hat.
igmpproxy unterstützt nur igmpv2. Eigentlich sollte v3 abwärtskompatibel
sein....
Mit folgenden Patches wurde versucht, dass der igmpproxy auch v3 kann:
http://wl500g.googlecode.com/svn/!svn/bc/4526/branches/sdk510/igmpproxy/
000-build.patch
001-zeroaltnet.patch
002-timer.patch
004-local.patch
005-disabled.patch
006-daemon.patch
007-rfc2113.patch
020-whitelist.patch
030-logging.patch
040-align.patch
050-igmpv3-stub.patch
060-multiple-origins.patch
Immerhin spricht dann der igmpproxy mit der Telekom v3. Intern aber v2
zum MR und der MR dann auch v2 mit dem igmpproxy .
Das Bild friert aber weiterhin ein.
Die Patches sind anscheinend nicht alle sauber, oder zu Ende
implementiert. In mehreren Tests wurde auf der Console v2 gemeldet. Aber
per Wireshark sieht man korrekt v3. Also aufpassen.
An meinem Router kann ich sehen, dass die Streams auch korrekt ankommen
und Bandbreite belegen. Allerdings routet igmpproxy diese nicht weiter.
Mit einem dd-wrt läuft weiterhin IP-TV. Hier wäre interessant, ob da
auch schon auf v3 gewechselt wurde.
Ergebnisse von weiteren Distris wie pfsense und co wären auch sehr
hilfreich.
Eigentlich nicht erwünscht, aber die Diskussion läuft auch außerhalb
fli4l. Deswegen der Link noch:
http://www.onlinekosten.de/forum/showthread.php?t=116415&page=38
net(t)forum
Ich habe auch mal spline.fli4l.dev einbezogen, falls sich ein "linux
multicast spezialist" dort befindet. :-)
Viele Grüße
Stephan
Hallo,
> Auch mit der aktuellen Tarball Version.
> Ich habe den Speedport rangeschaltet. Dann gehts erstmal wieder.
> Eigentlich sollte es relativ automatisch funktionieren.
> a) Routen für VLAN8 werden per DHCP (Option 121) propagiert.
> --> fli4l übernimmt diese:
> (Eth2 = Vlan8)
> cerberus 3.9.0-rev27690-testing # ip route
> default dev ppp0 scope link
> 87.140.255.0/25 via 93.237.63.254 dev eth2 metric 205
> 93.237.0.0/18 dev eth2 proto kernel scope link src 93.237.25.88
> metric 205
> 193.158.132.189 via 93.237.63.254 dev eth2 metric 205
> 217.0.119.37 dev ppp0 proto kernel scope link src 79.248.126.6
Auch mal die iptables kontrolliert ????
> b) igmp-proxy:
> IGMP_PROXY_ALT_N='3'
# number of IP addresses for
>
> multicast sources
> 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.35.0/24' # Required T-Home
>
> Was von den Routen oben muss ggf. noch beim igmp eingetragen werden?
Gruß Roland
Posted by Stephan Sanders on Sat, 01 Jun 2013 21:50:54 GMT
net(t)forum
Hallo Roland,
Am 01.06.2013 23:00, schrieb Roland Franke:
>
> Auch mal die iptables kontrolliert ????
Das mache ich morgen nochmal.
Aber bei einem SD Stream der am WAN Port ankommt, sollten die FW Counter
ordentlich steigen. Das wäre mir im WebIf sofort aufgefallen.
>
>>
>>
>>
>>
>>
>>
multicast sources
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
Was von den Routen oben muss ggf. noch beim igmp eingetragen werden?
Das habe ich schon versucht. Das sind ja nur die Upstream Adressen. Und
die Source-IPs der IP-TV Streams liegen alle im 193.158.35.0/24.
Also nichts neues.
VG
Stephan
Subject: [gelöst] Re: 3.4.0 und VDSL + IP-TV
Posted by Stephan Sanders on Sun, 02 Jun 2013 05:57:19 GMT
Hallo Leute,
Bei Onlinekosten.de [1] hat "bog" das Phänomen auf seinem WRT weiter
analysiert und die Lösung gefunden.
Folgende Lösung bringt das IP-TV am fli4l wieder zum fliegen:
Base Config:
(neue statische Route)
IP_ROUTE_N='1'
# number of additional routes
IP_ROUTE_1='193.158.34.0/23 ethX.8' # Device for DHCP towards Telekom
igmp Config:
IGMP_PROXY_ALT_N='3' # number of IP addresses for multicast sources
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
net(t)forum
NET_3 ist jetzt ein /23. Daher bitte ändern.
Viele Grüße und einen schönen Sonntag
Stephan
[1] http://www.onlinekosten.de/forum/showthread.php?t=116415&page=38
Subject: Re: [gelöst] Re: 3.4.0 und VDSL + IP-TV
Posted by B. Sprenger on Sun, 02 Jun 2013 13:05:07 GMT
Hallo zusammen,
> Hallo Leute,
>
> Bei Onlinekosten.de [1] hat "bog" das Phänomen auf seinem WRT weiter
> analysiert und die Lösung gefunden.
>
> Folgende Lösung bringt das IP-TV am fli4l wieder zum fliegen:
>
> Base Config:
> (neue statische Route)
>
> IP_ROUTE_N='1'
# number of additional routes
> IP_ROUTE_1='193.158.34.0/23 ethX.8' # Device for DHCP towards Telekom
>
> igmp Config:
>
> IGMP_PROXY_ALT_N='3' # number of IP addresses for multicast sources
> 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
>
> NET_3 ist jetzt ein /23. Daher bitte ändern.
>
Ich habe die versucht die Lösung umzusetzen.
Es hat zuerst nicht funktioniert
Bis ich dann festgestellt habe, dass bei mir 193.158.35.0 eingetragen war.
Nach der Korrektur auf ..34.0 hat es dann funktioniert.
Bei meinen Routern habe ich allerdings einen vierten Eintrag
IGMP_PROXY_ALT_NET_4='192.168.2.0/24'# address range of my IPTV-box
Habt ihr den Eintrag nicht?
net(t)forum
LG
Boris
Posted by Stephan Sanders on Sun, 02 Jun 2013 16:26:13 GMT
Hallo Boris,
Am 02.06.2013 15:05, schrieb B. Sprenger:
> Bis ich dann festgestellt habe, dass bei mir 193.158.35.0 eingetragen war.
> Nach der Korrektur auf ..34.0 hat es dann funktioniert.
193.158.34.0/23 besteht aus zwei /24 Netzwerken (193.158.34.0 und
193.158.35.0)
Die meisten sender sind im 34er Netz. Aber einige anscheinend auch schon
im 35er. Theoretisch reicht das für bis zu 512 Sender.
> Bei meinen Routern habe ich allerdings einen vierten Eintrag
> IGMP_PROXY_ALT_NET_4='192.168.2.0/24' # address range of my IPTV-box
Das vierte Netz habe ich bei mir nicht drin. Mit funktionierte es bei
mir in der Upstream Section vorher auch schon nicht.
In der Downstream Section (allerdings von Hand editiert) habe ich meinen
Receiver eingetragen, um die Meldung "BlaBla is not a valid..."
loszuwerden :-) Diese tritt aktuell aber auch nicht mehr auf.
Viele Grüße
Stephan
Posted by B. Sprenger on Mon, 03 Jun 2013 05:52:50 GMT
Hallo Stephan,
>
>
>> Bei meinen Routern habe ich allerdings einen vierten Eintrag
>> IGMP_PROXY_ALT_NET_4='192.168.2.0/24' # address range of my IPTV-box
>
> Das vierte Netz habe ich bei mir nicht drin. Mit funktionierte es bei
> mir in der Upstream Section vorher auch schon nicht.
> In der Downstream Section (allerdings von Hand editiert) habe ich meinen
> Receiver eingetragen, um die Meldung "BlaBla is not a valid..."
> loszuwerden :-) Diese tritt aktuell aber auch nicht mehr auf.
net(t)forum
Ich habe diese Meldung immer noch.
Was bedeutet UPSTREAM und DOWNSTREAM Section?
Ich würde diese Meldung auch gerne eliminieren, da ich einen
SYSLOG-Client habe und das Logprotokoll unnötig aufgebläht wird.
Welche Datei ist da zu editieren? Und was muss ich eintragen?
Wäre schön, wenn ich die Meldung auch loswerden könnte.
LG
Boris
Subject: Aw: 3.4.0 und VDSL + IP-TV
Posted by DD50 on Mon, 03 Jun 2013 11:23:27 GMT
Hi,
ich habe mal den igmpproxy mit dem Patch auf V3 erstellt. Leider kann man hier keine
anhänge machen. Deswegen habe ich ihn hochgeladen.
Gruß
http://www.sendspace.com/file/5tv10i
net(t)forum

Subject: 3.4.0 und VDSL + IP-TV Posted by rene reckschwardt on Wed

Transcription

Similar documents

Cisco Catalyst Switches der Serie 3850

Subject: Problem Sil3114 SATA-Controller Posted by

UNIVERSITÄT LEIPZIG Diplomarbeit

QuickTime Streaming Server 4.1 - Hit - FH

Tor für die Fritzbox Tor beschleunigen Fritzbox sichern