Protokoll 2 (IGMP) weiterleiten?

dk5ras · Beitrag von **dk5ras** » 17 Jan 2008, 20:46

Es wäre zu einfach gewesen

Ich habe alles x-male durchgegangen und auch beide genannten Varianten (Sperroute und INTRANET anders taggen) getestet - nix! Kann es sein, daß der Mediareceiver auch nach außen per UDP kommuniziert? Bei all dem Hin und Her kam eine email von der firewall - das sieht für mich aus, also wollte das IPTV-Kastl per UDP 'rausfunken:

Date: 1/17/2008 18:18:36

The packet below

Src: 10.0.0.110:1036 {iptv} Dst: 239.255.255.250:8082 (UDP)

MAC-Header (14 Bytes)

01 00 5e 7f ff fa 00 d0 e0 93 c5 4c 08 00 | ..^..... ...L..

IP-Packet (128 Bytes):

45 60 03 d3 0a b4 00 00 01 11 b0 9e 0a 00 00 6e | E`...... .......n
ef ff ff fa 04 0c 1f 92 03 bf be 05 01 17 f1 9d | ........ ........
4c 6d 0c 3a cb c6 f3 4d 09 89 7d 2e b1 8a b9 5f | Lm.:...M ..}...._
0a 17 9f dc b3 4e 4f 54 49 46 59 20 2a 20 48 54 | .....NOT IFY * HT
54 50 2f 31 2e 31 0d 0a 78 2d 74 79 70 65 3a 20 | TP/1.1.. x-type:
64 76 72 0d 0a 78 2d 6c 6f 63 61 74 69 6f 6e 3a | dvr..x-l ocation:
20 68 74 74 70 3a 2f 2f 31 30 2e 30 2e 30 2e 31 | http:// 10.0.0.1
31 30 3a 38 30 38 30 2f 64 76 72 66 73 2f 69 6e | 10:8080/ dvrfs/in

matched this filter rule: intruder detection
filter info: packet received from invalid interface INTERNET

10.0.0.1 ist mein Lancom 1823, 10.0.0.110 das IPTV-Gerät. Kann natürlich sein, daß das ganz was Anderes ist, irgendwelche Kontroll-Informationen, oder was vom Videorekorder...

backslash · Beitrag von **backslash** » 17 Jan 2008, 21:10

Hi dk5ras

Dann ändere doch mal die Firewall-Regel für das IGMP (also die abgehende Regel) so ab, daß sie für alle Dienste gilt.

Und stell vorübergehend mal die Aktion für das IDS auf "übertragen" (dann meckert die Firewall nicht dazwischen)

Das Problem ist halt, daß ich hier mangels eines solchen Anschlussee nur im trüben fischen kann...

Gruß
Backslash

dk5ras · Beitrag von **dk5ras** » 17 Jan 2008, 21:30

Ja, klar, ist alles Bastelei in der Ferndiagnose

IDS übertragen hatte ich eh schon, die Meldung kam dann, als ich wieder am Herstellen des Urzustandes war und der receiver noch angesteckt war. Bei den Regeln hatte ich das eigentlich schon mit allen Varianten durch, udp dazu erlauben, alles erlauben, Prot. 2 zusammen mit IGMP, usw. Aber ich werde das nochmal etwas strukturierter ausprobieren, entweder heute noch, oder dann halt erst morgen. Du meinst also, die routing table paßt so, und ich müsse eher noch an der firewall spielen? Werde mich darauf konzentrieren...

Viele Grüße!

dk5ras · Beitrag von **dk5ras** » 17 Jan 2008, 22:00

Tut nicht. Ich gebe es auf für heute und gehe schlafen, offenbar taugt das Gerät für IGMP einfach nicht

Schade.

Danke für all den support, ujnd viele Grüße!

twister996 · Beitrag von **twister996** » 19 Jan 2008, 10:22

Hallo zusammen,

ich habe die hier beschriebenen Einträge jetzt zig Mal eingetragen, kontrolliert, wieder gelöscht, neu eingetragen... aber dieses verflixte iptv will einfach nicht fkt. Das Bild bleibt nach ein paar Sek immer stehen.

Kann es sein, dass sich die 1823 hier anders verhält als die 1811 (mit der backslash ja wohl getestet hat)?

Ich will dieses blöde Speedport W701V-Ding einfach nicht auspacken und anschliessen, aber wenn ich es mit der Lancom nicht hinbekomme

Übrigens: im Trace vom 1823 sehe ich zu der Zeit, wenn das Bild stehen bleibt, Timeout vom IP-Masquerading:
[IP-masquerading] 2008/01/19 10:05:18,570
Close: UDP 192.168.11.218, 4317 => 60335 Timeout

[IP-masquerading] 2008/01/19 10:05:18,570
Close: UDP 192.168.11.218, 4253 => 60399 Timeout

[IP-masquerading] 2008/01/19 10:05:18,570
Close: UDP 192.168.11.218, 1062 => 61268 Timeout

Die ...218 ist der Mediareceiver. Kann das was mit dem Problem zu tun haben? Und wenn ja: hat jemand eine Idee, woher das kommt?

Vielen Dank für Eure Hilfe!

ittk · Beitrag von **ittk** » 19 Jan 2008, 10:57

Hi,

du koenntest probehalber mal unter IP-Router -> Maskierung den UDP-Agingwert (default) 20 sec auf z.B. 300 sec hochsetzen.

Aendert das etwas an dem Verhalten des Mediareceivers?

twister996 · Beitrag von **twister996** » 19 Jan 2008, 11:06

...Danke für den Tip. Ergebnis: Im Trace kommt der Timeout jetzt später - das Bild bleibt aber nach wie vor nach der gleichen Zeit (ca 10 Sek) stehen.

Scheint also nicht an dem Masquerading zu liegen??

ittk · Beitrag von **ittk** » 19 Jan 2008, 11:19

Hi,

korrekt, das NAT ist nun auszuschliessen.

twister996 · Beitrag von **twister996** » 19 Jan 2008, 11:23

*verzweifelt* hast Du vielleicht noch eine Idee?

ittk · Beitrag von **ittk** » 19 Jan 2008, 11:34

Hi,

leider nein, da ich genauso wie Backslash keinen VDSL / IPTV-Anschluss zum Testen habe.

twister996 · Beitrag von **twister996** » 19 Jan 2008, 12:07

schade!
Aber vielleicht hat jemand noch eine Idee hierzu: ich habe weitere Traces gemacht und bin über folgende IGMP-Meldungen gestolpert:

[Ethernet] 2008/01/19 11:51:04,960
Received 60 byte Ethernet packet via LAN-1:
-->IEEE 802.3 Header
Dest : 01:00:5e:00:00:16
Source : 00:1a:c3:4f:70:13
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 24
Type of service : Precedence 3
Total length : 40
ID : 15250
Fragment : Offset 0
TTL : 1
Protocol : IGMP
Src Address : 192.168.11.218
Dest Address : 224.0.0.22
-->IPv4 Header Options
Router Alert : Router shall examine packet
-->IGMP Header
Type : Version 3 Membership Report
ChkSum : 19986
-->IGMPv3 Group Record
Record Type : CHANGE_TO_INCLUDE_MODEMulticast Address : 239.35.157.200Trailer : 00 00 00 00 00 00 ......

[Ethernet] 2008/01/19 11:51:04,980
Received 60 byte Ethernet packet via LAN-1:
-->IEEE 802.3 Header
Dest : 01:00:5e:00:00:16
Source : 00:1a:c3:4f:70:13
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 24
Type of service : Precedence 3
Total length : 40
ID : 15251
Fragment : Offset 0
TTL : 1
Protocol : IGMP
Src Address : 192.168.11.218
Dest Address : 224.0.0.22
-->IPv4 Header Options
Router Alert : Router shall examine packet
-->IGMP Header
Type : Version 3 Membership Report
ChkSum : 19730
-->IGMPv3 Group Record
Record Type : CHANGE_TO_EXCLUDE_MODEMulticast Address : 239.35.157.200
Trailer : 00 00 00 00 00 00 ......

Leider fehlt mir hier wirklich das Hintergrundwissen... Aber dieses EXCLUDE macht mich stutzig... sagt einem das was?

Danke!

ittk · Beitrag von **ittk** » 19 Jan 2008, 16:53

Hi,

kurz gesagt muesste folgendes damit gemeint sein: das kein IGMP auf dem LANCOM aktiv ist (hat es noch nicht) und somit kein Mitglied einer Multicast-Gruppe includiert d.h. gezielt angeprochen werden kann.

dk5ras · Beitrag von **dk5ras** » 20 Jan 2008, 10:24

Moin,

auch bei mir trotz aller Verrenkungen kein Erfolg mit igmp. Kann ich denn irgend etwas unternehmen, der Sache systematisch auf den Grund zu gehen? Sieht jemand einen Sinn darin, mit wireshark auf den interfaces mal mitzuschnüffeln? Mein switch soll ports spiegeln können, habe das noch nie getestet, aber nun ja, vielleicht kann ich ja bei der Sache noch etwas lernen?

Noch scheue ich es ein wenig, die Büchse mal zu resetten und komplett neu einzurichten, aber vielleicht ist irgendo versteckt in der config etwas, das igmp erfolgreich behindert? Kann ja mal ein minimal-setup installieren, nur VDSL-PPPoE-Einwahl, und dann gleich alles für igmp vorsehen. Sollte ich damit Erfolg haben, Schritt für Schritt weitermachen (während der Fernseher läuft) und notgedrungen alles händisch neu erstellen, bis der Fernseher wieder abbricht, oder eben letztlich bis zum Schluß alles tut. Sollte ich keinen Erfolg haben, dann wäre wenigstens bewiesen, daß es etwas Prinzipielles ist -> altes setup drauf, und die Sache vergessen

ittk · Beitrag von **ittk** » 20 Jan 2008, 10:53

Hi,

ich habe mir nun mal Rougu's Antwort durchgelesen und mit deinen trace ethernet verglichen. Kann es einfach sein, dass der T-Home IPTV Traffic nicht durch die Firewall zum Media-Reciever durchkommt?

Es wird anscheinend die Multicast-Adresse: 239.35.157.200 benoetigt. Das ist also kein oeffentlich-rechtlicher Sender, wie ich erkennen kann, sondern ein privater.

Bei der Einrichtung des LANCOM-Routers gelten die untenstehenden Angaben auch bezueglich der MTU am Ethernetinterface!

Code: Alles auswählen

T-Home 
- using admin-scoped multicasts 239.35.0.0/16 
- Servers are in 193.158.34.0/23 (TOIAG-USINGEN-IPTV-01) 
- Streams are using Port 10000/udp 
- Upstream ethernet interface to VDSL modem must use VLAN id 7 and MTU 1476 (1492-16) 
To speed up channel switching the first ten seconds of every channel switched to are sent by Unicast, hence you have a 1:1 link to the server. So if one of the nodes between your receiver and the streaming server is not capable of doing multicast, your picture and sound will just freeze after 10 seconds. 
- All communication between the T-Home stream servers and the STB are encrypted, very likely using public key encryption. The Öffentlich-Rechtlichen are the exception here, their stream is unencrypted and partially viewable with the latest builds of VideoLan.

Vielleicht ist es ja letzendlich genau das Problem, dass bisher nicht die admin-scoped multicasts 239.35.0.0/16 durch die Firewall zum Media-Reciever und die MTU am WAN-interface auf 1476 herabgesetzt wurden.

Wie waere es mit einer Modifizierung eurer Konfig in diesen beiden Punkten, um auch dieses Problem auszuschliessen.

Ein trace # ip-r # fi, um zu sehen, ob das Routing /Routing-Tabelle sowie die Firewall bei den o.g. Multicast-Pakete(n) (239.35.157.200) des IPTV nicht eingreift. Ferner koennte noch ein trace # et hilfreich sein.

Ferner koennte es zu Testzwecken nicht schaden die Firewall so zu konfigurieren, dass sie bei IDS und DoS-Paketen die Aktion uebertragen durchfuehrt.

twister996 · Beitrag von **twister996** » 20 Jan 2008, 14:04

Hi,

danke für die Hinweise.
Ich habe mal einen ETH-Port am Lancom auf Monitor umgestellt und mit Wireshark geschaut, was da passiert:

- von der WAN-Seite kommen alle 15 Sekunden IGMP-Daten rein, z.B.
1479 1388.335892 217.0.119.87 224.0.0.1 IGMP V3 Membership Query

Ich interpretiere das so, dass T-Home darüber eine Anfrage starten "Wer will denn alles mitspielen?"

Diese über das WAN-Interface (ETH1 als DLS zum VDSL-Modem konf.) reinkommenden Daten kriege ich aber "zum Verrecken" nicht in der Firewall ausgewertet - selbst wenn ich ein DENY-ALL auf der Firewall mache, sehe ich DIESE Pakete nicht. So - und wenn die auf der Firewall nicht erkannt werden, erfolgt auch kein Tagging und somit fkt. auch das tag-basierende Routing nicht.
Ich vermute also, dass irgendwas verhindert, dass die Pakete zur Firewall-Auswertung gelangen.

Könnte meine Theorie stimmen? Und falls ja: Habt Ihr eine Idee, warum man die in der Firewall nicht "greifen" kann?

Selbst mit einem TRACE + ALL finde ich diese Daten nicht (einfach mal nach 224. gesucht) - schluckt der LANCOM die Pakete....?

Bitte helft!!!!... ich mache seit gestern morgen nix anderes mehr

übrigens: Die MTU-Size habe ich probehalber auch mal runtergesetzt, keine Veränderung. IDS- und DoS-Pakete habe ich schon auf Durchlassen gesetzt gehabt, ebenfalls keine Veränderung.