Protokoll 2 (IGMP) weiterleiten?

[dk5ras]

Ahja, also der Lancom rein als switch, ohne routing...verstehe. Ich will ja auch das W900V loswerden, braucht sinnlos Strom (wenn auch wenig) und stürzt andauernd ab, wenn auf der Leitung bissl was los ist.

[twister996]

Hi Ralph,
mit dem Lancom mache ich VPN und VoIP-Anbindung (Swyx) in die Firma, und die NBs sind darüber per WLAN angebunden - also mehr als reiner Switch - und daher will ich ihn auch nicht austauchen...
gruß
Holger

[dk5ras]

Ja, eh klar - und bei mir macht das Ding WLAN-VoIP nach ISDN für die Telephone in der Wohnung, dazu das eigentliche routing zum server, und natürlich WLAN für die notebooks. Sozusagen doppeltes NAT, der Lancom als exposed host hinter dem Speedport-Dings. Wenn ich die portforwardings von dem Speedport erledigen lasse, schmiert es täglich einmal ab, so ist es "nur" ca. wöchentlich.
Der IPTV-receiver hängt direkt im "ersten" LAN am Speedport. Nachdem die DECT-Telephone nun abgeschafft sind, ist der Speedport an sich sinnlos und nur noch wegen IPTV da.

Dann wollen wir mal sehen, ob das noch was wird...

Viele Grüße!

[dk5ras]

Moin,

um zu sehen, ob es evtl. am PPPoE liegt, werde ich heute Abend mal in meinem bisherigen setup die routen entspr. einrichten und den IPTV-receiver an den Lancom hängen, also doppelt geNATtet.

[twister996]

...habe das jetzt auch mal probiert, hat an der Sache nichts verändert...
ABER im Trace ist mir folgendes aufgefallen:

[Ethernet] 2008/01/24 16:48:08,030
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 : 2018
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 : 58791
-->IGMPv3 Group Record
Record Type : CHANGE_TO_INCLUDE_MODEMulticast Address : 239.35.6.51
Trailer : 00 00 00 00 00 00 ......


[Bridge] 2008/01/24 16:48:08,030
Bridge frame coming from ifc LAN-1:
00:1a:c3:4f:70:13-->01:00:5e:00:00:16
-->multi/broadcast
-->forwarding into own LSL stack
-->forwarding 60 bytes to ifc WLAN-1


[Ethernet] 2008/01/24 16:48:08,050
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 : 2019
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 : 58535
-->IGMPv3 Group Record
Record Type : CHANGE_TO_EXCLUDE_MODEMulticast Address : 239.35.6.51
Trailer : 00 00 00 00 00 00 ......


[Bridge] 2008/01/24 16:48:08,050
Bridge frame coming from ifc LAN-1:
00:1a:c3:4f:70:13-->01:00:5e:00:00:16
-->multi/broadcast
-->forwarding into own LSL stack
-->forwarding 60 bytes to ifc WLAN-1

"...into OWN LSL stack..." und "...forwarding to WLAN-1..."

Das lese ich als "oh, ein Multi-/Broadcast - den verleibe ich mir ein und leite ihn an das WLAN-Interface weiter...". Macht das Sinn?

Problem ist nach wie vor, dass ich diese 224er-Multicasts NICHT per Firewall-Regel eingefangen bekomme, egal wie eng oder weit ich die Regel definiere.

Any idea?

[dk5ras]

Moin,

nö, net wirklich, außer, daß das halt schon noch nach firmware riecht. Leider muß ich heute Überstunden machen, und morgen fahre ich in Kurzurlaub, werde also wohl vor nächster Wochen icht mehr zum Experimentieren kommen.

[backslash]

Hi twister996, Hi dk5ras

es liegt tatsächlich am PPPoE...

Der ursprüngliche Entwickler des IGMP-Moduls hat das ganze für eine reine LAN-Anwendung implementiert und daher noch den Ethernet-Header geprüft - der bei einer PPP(oE)-Verbindung entweder gar nicht vorhanden ist oder halt nicht das Protokoll 0x0800 (IP) beinhaltet... Desweiteren wurde die Prüfsumme nur für IGMPv1/v2 geprüft und nicht für das ganze Paket...

Ich schicke euch eine neue Firmware, bei der es dann auch mit PPPoE (und hoffentlich auch IGMPv3) funktioniert:

Code: Alles auswählen

[Ethernet] 1900/01/01 00:36:49,620
Received 60 byte Ethernet packet via DSL-1:
-->IEEE 802.3 Header
Dest                : 06:a0:57:0f:c9:f8 (LANCOM(local-1) 0f:c9:f8)
Source              : 00:a0:57:06:d0:3e (LANCOM 06:d0:3e)
Type                : PPPoE Session
-->PPPoE Session Packet
Version             : 1
Type                : 1
Code                : Session
Session-ID          : 24
Payload Length      : 30
--->PPP Payload
Protocol            : 33
Length              : 28
Id                  : 0
Protocol Code       : 69
Protocol Data       : 2f 27 00 00 01 02 a0 78 /'.....x
                      0a 00 00 38 e0 00 00 09 ...8....
                      12 00 0d f6 e0 00 00 09 ........
Packet Trailer      : 00 00 00 00 00 00 00 00 ........
                      00 00                   ..


[IGMP] 1900/01/01 00:36:49,630
Received v1 report for group 224.0.0.9 from 10.0.0.56 at WAN, MULTI
=> Forward to router

in der wagen Hoffnung, daß es nun endlich funiktionieren könnte...

Gruß
Backslash

[twister996]

Hey,
das sieht doch schon besser aus! Tatsächlich werden die reinkommenden Pakete als IGMP erkannt, mit Routing-Tag 2 versehen und ins LAN gepumpt! Sehr schön!

Aber... : die rausgehenden Pakete werden nach wie vor bei mir nur im LAN bekannt gemacht, siehe o.a. Trace. Hier bekomme ich das Tagging 1 nicht hin und dementsprechend wird auch nichts gen Internet geroutet...

@Backslash: so, nur noch wenige Meter bis zum Ziel...

[dk5ras]

Ich habe nur einen kurzen Test machen können, im standard-setup mit meinem doppelten NAT sowie mit PPPoE-Einwahl vermittels LC 1823 - nix in beiden Varianten. Falls sich noch etwas ergibt, kann ich ggf. nach 22 Uhr oder morgen in aller Frühe noch einen Kurztest machen, ansonsten bin ich dann bis Sonntag Abend außen vor, da unterwegs.

Viele Grüße an alle, die noch nicht das Interesse verloren haben

[backslash]

Hi twister996

Das lese ich als "oh, ein Multi-/Broadcast - den verleibe ich mir ein und leite ihn an das WLAN-Interface weiter...". Macht das Sinn?

ja, den das WLAN und LAN sind ja über eine Bridge gekoppelt, d.h. alle Multicasts die im LAN reinkommen müssen auch aufs WLAN...

genauso müssen alle Multicastst die ins LAN gesendet werden auch ins WLAN gesendet werden....

Wenn du die Multicasts vom WLAN fernhalten willst, dann mußt du das über die Protokollfilter der LAN/WLAN-Bridge erschlagen...

Aber... : die rausgehenden Pakete werden nach wie vor bei mir nur im LAN bekannt gemacht, siehe o.a. Trace.

Tauchen sie denn nun im IGMP-Trace auf?

egal.. ich baue nochmal eine Firmware, in der das IGMP auch angibt, wenn es Pakete verwirft - inclusive Grund...


Gruß
Backslash

[twister996]

Hi Backslash,

nee, ich sehe sie weder im IGMP- noch Firewall noch IP-Routing.
Man sieht sie nur im ETH-Trace.

Gruß
Twister996

[twister996]

...ich würde ja sehr gerne besseres berichten, aber da passiert nicht viel mehr:

[Packet-dump] 2008/01/24 20:35:24,160
Packet data:
46 c0 00 24 ca 42 00 00 01 02 29 78 d9 00 77 57
e0 00 00 01 94 04 00 00 11 64 ec 8c 00 00 00 00
02 0f 00 00

[IGMP] 2008/01/24 20:35:39,160
Received v2 query for group 0.0.0.0 from 217.0.119.87 at WAN, INTERNET
=> Forward to router


[Packet-dump] 2008/01/24 20:35:39,160
Packet data:
46 c0 00 24 cd 1a 00 00 01 02 26 a0 d9 00 77 57
e0 00 00 01 94 04 00 00 11 64 ec 8c 00 00 00 00
02 0f 00 00

[IGMP] 2008/01/24 20:35:54,160
Received v2 query for group 0.0.0.0 from 217.0.119.87 at WAN, INTERNET
=> Forward to router


[Packet-dump] 2008/01/24 20:35:54,160
Packet data:
46 c0 00 24 d0 17 00 00 01 02 23 a3 d9 00 77 57
e0 00 00 01 94 04 00 00 11 64 ec 8c 00 00 00 00
02 0f 00 00

Wirkliche Gründe für die Ablehnung sehe ich hier nicht....?

Mir scheint, der Lancom interpretiert diesen von innen kommenden IGMP nach wie vor als intern und gibt ihn daher erst gar nicht an den Router weiter.

Gruß
twister996

[twister996]

...Nachtrag:

Habe mir gerade noch mal nen ETH-Trace angeschaut. Da sehe ich jetzt die 239.255.255.250 statt 224.0.0.0. Die gehört auch in den MC-Bereich, oder? Ich habe die Firewall und den Router schon mal testweise umkonfiguriert - vielleicht habe ich aber dabei was falsch gemacht.
Gibt es dabei etwas besonderes zu beachten?

Gruß
Twister996

[Ethernet] 2008/01/24 20:40:49,400
Received 491 byte Ethernet packet via LAN-1:
-->IEEE 802.3 Header
Dest : 01:00:5e:7f:ff:fa
Source : 00:1a:c3:4f:70:13
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : Precedence 3
Total length : 477
ID : 1964
Fragment : Offset 0
TTL : 1
Protocol : UDP
Src Address : 192.168.11.218
Dest Address : 239.255.255.250
-->UDP Header
Src Port : 1037
Dest Port : 8082
Length : 457
Body : 01 15 2a 49 e0 40 68 43 ..*I.@hC
cb a5 32 f8 47 b1 bc 05 ..2.G...
c6 19 1c a5 1e 57 9d cf .....W..
4e 4e 4f 54 49 46 59 20 NNOTIFY
2a 20 48 54 54 50 2f 31 * HTTP/1
2e 31 0d 0a 78 2d 74 79 .1..x-ty
70 65 3a 20 64 76 72 0d pe: dvr.
0a 78 2d 6c 6f 63 61 74 .x-locat
69 6f 6e 3a 20 68 74 74 ion: htt
70 3a 2f 2f 31 39 32 2e p://192.
31 36 38 2e 31 31 2e 32 168.11.2
31 38 3a 38 30 38 30 2f 18:8080/
64 76 72 66 73 2f 69 6e dvrfs/in
66 6f 2e 78 6d 6c 0d 0a fo.xml..
78 2d 64 65 62 75 67 3a x-debug:
20 68 74 74 70 3a 2f 2f http://
31 39 32 2e 31 36 38 2e 192.168.
31 31 2e 32 31 38 3a 38 11.218:8
30 38 30 0d 0a 78 2d 66 080..x-f
69 6c 74 65 72 3a 20 63 ilter: c
36 32 35 34 63 37 38 2d 6254c78-
61 34 39 66 2d 34 32 33 a49f-423
36 2d 39 63 37 30 2d 36 6-9c70-6
38 34 62 32 64 64 33 39 84b2dd39
39 36 66 0d 0a 78 2d 6c 96f..x-l
61 73 74 55 73 65 72 41 astUserA
63 74 69 76 69 74 79 3a ctivity:
20 31 2f 32 34 2f 32 30 1/24/20
30 38 20 37 3a 33 33 3a 08 7:33:
32 32 20 50 4d 0d 0a 0d 22 PM...
0a 3c 6e 6f 64 65 20 63 .<node c
6f 75 6e 74 3d 27 31 36 ount='16
39 27 3e 3c 61 63 74 69 9'><acti
76 69 74 69 65 73 3e 3c vities><
74 75 6e 65 20 73 72 63 tune src
3d 27 75 64 70 3a 2f 2f ='udp://
32 33 39 2e 33 35 2e 36 239.35.6
2e 35 31 3a 31 30 30 30 .51:1000
30 3a 31 39 32 36 30 64 0:19260d
39 63 2d 62 64 64 37 2d 9c-bdd7-
34 31 64 62 2d 39 64 61 41db-9da
35 2d 32 38 63 31 64 38 5-28c1d8
61 33 32 39 30 33 27 20 a32903'
70 69 70 65 3d 27 46 55 pipe='FU
4c 4c 53 43 52 45 45 4e LLSCREEN
27 20 63 74 3d 27 30 78 ' ct='0x
63 62 34 33 36 36 38 36 cb436686
36 66 35 39 63 32 65 39 6f59c2e9
27 20 70 69 6c 3d 27 30 ' pil='0
78 30 27 20 72 61 74 65 x0' rate
3d 27 30 78 39 37 65 33 ='0x97e3
62 66 27 20 73 74 6f 70 bf' stop
70 65 64 3d 27 66 61 6c ped='fal
73 65 27 2f 3e 3c 2f 61 se'/></a
63 74 69 76 69 74 69 65 ctivitie
73 3e 3c 2f 6e 6f 64 65 s></node
3e >

[twister996]

sorry, aber ich war viel zu voreilig und mülle hier das Forum zu ...
Es sind nach wie vor auch 224.0...-Adr. dabei.

siehe nachfolgenden ETH-Trace, der aber dann im Anschluss nicht als separates IGMP getraced wird.

[Ethernet] 2008/01/24 20:45:13,190
Received 70 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 : 56
ID : 2310
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 : 26046
-->IGMPv3 Group Record
Record Type : MODE_IS_EXCLUDEMulticast Address : 239.35.157.200
-->IGMPv3 Group Record
Record Type : MODE_IS_EXCLUDEMulticast Address : 239.35.6.51
-->IGMPv3 Group Record
Record Type : MODE_IS_EXCLUDEMulticast Address : 239.255.255.250

[backslash]

Hi twister996

Wirkliche Gründe für die Ablehnung sehe ich hier nicht....?

dann kommen die Pakete auch nicht beim IGMP an - ggf. nicht mal beim IP

Hantierst du irgendwie mit VLANs - was sagt ein VLAN-Trace?

Meldet sich irgendwie die Firewall zu Wort (=> firewall-Trace)?

was passiert, wenn du das WLAN abkemmst - d.h. aus der Bridgegruppe herausnimmst...

Oder anders herum: was passiert, wenn du das LAN-Interface aus der Bridgegruppe herausnimmst und dein Intranet direkt an das LAN-Interface bindest, statt an die Bridge-Gruppe.

Kannst du mal mit Wireshark mittracen, wie die Multicasts vom LAN aussehen (denn im Ethernet-Trace werden die Pakete ja schon interpretiert, wobei einige Dinge aus den Headern unter den Tisch fallen könnten)

Gruß
Backslash