Moin!
Ich habe mir hier ein LC1823 (LCOS 7.22) zum Test an VDSL der Telekom zugelegt. Erst mal off-topic, aber ich muß es einfach loswerden - eine derart unübersichtliche Konfigurationsoberfläche und ein derart besch*#*enes webinterface hatte ich nicht erwartet, ebenfalls nicht, daß ein dualband-AP nur entweder 2.4 oder 5 GHz anbietet und nicht beides gleichzeitig, aber nun ja, hat ja auch nur 590 EUR gekostet, das Teil :-) Meine bisherigen Dualbander für ein Zehntel des Preises sind da schon weiter.
Jetzt aber zum Punkt - daß das Ding (noch) kein IGMP kann, war mir natürlich klar. Dennoch habe ich wenig herumgespielt, und was mit meinem popeligen DD-WRT-router astrein geht, bekomme ich einfach nicht hin. Beim DD-WRT-Teil reicht es, den IPTV-receiver als exposed host einzurichten, und schon funktioniert das streaming. Beim LC-Gerät tut sich da gar nix, auch hat es nicht funktioniert nach Deaktivieren der firewall, ebenfalls nicht, wenn man eine firewall-Regel einrichtet, die Protokoll 2 (eben IGMP) fest an eine MAC-Adresse pinnt.
Ansonsten, gibt es weiterführende Literatur als die Manuals, die einem den Umgang mit den LCs erleichtert? Die Dinger können ja wirklich enorm viel, aber in diesem grausigen UI muß man das erst mal alles finden und verstehen :(
Danke für Hinweise, und viele Grüße aus Fürth!
Ralph.
Protokoll 2 (IGMP) weiterleiten?
Moderator: Lancom-Systems Moderatoren
Moin,
und die ist nirgendwo intuitiv. Daß das Plugin zur Konfiguration der Firewall in der
WEBconfig fehlt, wie es die LANtools haben, ist sicher ein Problem, aber offensichtlich ist die
Menge der Nicht-Windows-Besitzer im angestrebten (Business-)Kundenkreis zu klein, als daß
an der Stelle Energie aufgewendet würde...
nicht zwei Sender gleichzeitig empfangen. Die Geräte, mit denen Du das vergleichst, haben vermutlich
zwei Funkmodule?
Sehen wollen...
LANCOMs sind - was die reine Hardware angeht - im Vergleich zu Consumer-Geräten deutlich
teurer. Das liegt einfach daran, daß LANCOM ein komplett eigenes Betriebssystem hat und
es selber (in Deutschland) weiterentwickelt. Für Business- und Projektkunden ist so etwas ein
wichtiges Argument, wenn man Bug-Reports nicht nach USA schicken muß und dann für die
Deutschland-spezifischen Probleme vielleicht in ein em Vierteljahr eine neue Firmware bekommt.
Der Aufpreis ist dann üblicherweise kein Thema...
Möglichkeit, das hintenherum durch irgendwelche NAT-Einträge freizugeben - das NAT greift nur
für TCP und UDP. IGMP und das daraus resultierende Multicast-Routing müßte der Router schon
selber machen. Ist nicht unmöglich, daß das irgendwann kommt, aber bedenke bitte auch, daß der
fernsehende Heimnutzer nicht die primäre Zielgruppe der LANCOMs ist
Multicast-Routing ist
- wenn man es für typische LANCOM-Anwendungen realisieren will - auch alles andere als trivial,
weil ein LANCOM-Router häufig deutlich mehr als eine WAN-Verbindung geöffnet hat - einfach alle
Multicasts von links nach rechts durchzuleiten, funktioniert da nicht.
Gruß Alfred
Meinst Du die Expertenkonfiguration? Das ist im wesentlichen ein Abbild der Kommandozeile,Erst mal off-topic, aber ich muß es einfach loswerden - eine derart unübersichtliche Konfigurationsoberfläche und ein derart besch*#*enes webinterface hatte ich nicht erwartet,
und die ist nirgendwo intuitiv. Daß das Plugin zur Konfiguration der Firewall in der
WEBconfig fehlt, wie es die LANtools haben, ist sicher ein Problem, aber offensichtlich ist die
Menge der Nicht-Windows-Besitzer im angestrebten (Business-)Kundenkreis zu klein, als daß
an der Stelle Energie aufgewendet würde...
Das kann ein Gerät mit nur einem Funkmodul prinzipbedingt nicht - mit einem Radio kannst Du auchebenfalls nicht, daß ein dualband-AP nur entweder 2.4 oder 5 GHz anbietet und nicht beides gleichzeitig,
nicht zwei Sender gleichzeitig empfangen. Die Geräte, mit denen Du das vergleichst, haben vermutlich
zwei Funkmodule?
Ein ADSL/ISDN-Router mit Analoganschlüssen und zwei Funkmodulen für 60 Euro?aber nun ja, hat ja auch nur 590 EUR gekostet, das TeilMeine bisherigen Dualbander für ein Zehntel des Preises sind da schon weiter.
Sehen wollen...
LANCOMs sind - was die reine Hardware angeht - im Vergleich zu Consumer-Geräten deutlich
teurer. Das liegt einfach daran, daß LANCOM ein komplett eigenes Betriebssystem hat und
es selber (in Deutschland) weiterentwickelt. Für Business- und Projektkunden ist so etwas ein
wichtiges Argument, wenn man Bug-Reports nicht nach USA schicken muß und dann für die
Deutschland-spezifischen Probleme vielleicht in ein em Vierteljahr eine neue Firmware bekommt.
Der Aufpreis ist dann üblicherweise kein Thema...
Multicast-Routing ist im LANCOM im Moment grundsätzlich nicht drin, und es gibt m.W. auch keineJetzt aber zum Punkt - daß das Ding (noch) kein IGMP kann, war mir natürlich klar. Dennoch habe ich wenig herumgespielt, und was mit meinem popeligen DD-WRT-router astrein geht, bekomme ich einfach nicht hin. Beim DD-WRT-Teil reicht es, den IPTV-receiver als exposed host einzurichten, und schon funktioniert das streaming. Beim LC-Gerät tut sich da gar nix, auch hat es nicht funktioniert nach Deaktivieren der firewall, ebenfalls nicht, wenn man eine firewall-Regel einrichtet, die Protokoll 2 (eben IGMP) fest an eine MAC-Adresse pinnt.
Möglichkeit, das hintenherum durch irgendwelche NAT-Einträge freizugeben - das NAT greift nur
für TCP und UDP. IGMP und das daraus resultierende Multicast-Routing müßte der Router schon
selber machen. Ist nicht unmöglich, daß das irgendwann kommt, aber bedenke bitte auch, daß der
fernsehende Heimnutzer nicht die primäre Zielgruppe der LANCOMs ist
Multicast-Routing ist- wenn man es für typische LANCOM-Anwendungen realisieren will - auch alles andere als trivial,
weil ein LANCOM-Router häufig deutlich mehr als eine WAN-Verbindung geöffnet hat - einfach alle
Multicasts von links nach rechts durchzuleiten, funktioniert da nicht.
Was fehlt Dir denn im Referenzmanual?Ansonsten, gibt es weiterführende Literatur als die Manuals, die einem den Umgang mit den LCs erleichtert? Die Dinger können ja wirklich enorm viel, aber in diesem grausigen UI muß man das erst mal alles finden und verstehen
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Moin,
wenn zwei Bänder vorhanden sind, dann sind da auch zwei Funkmodule drin - außer, man spart am letzten cent und setzt nur einen Basisbandchip ein und schaltet das frontend um. _Das_ hätte ich in _der_ Preisklasse nicht erwartet, aber nun ja. Also doch wieder ein zusätzlicher Accesspoint, um beider Bänder abzudecken. Gnarf. Dabei wollte ich Strom sparen...
Was das Config-Dingens angeht, das ist einfach nur wirr, in der deutschen wie in der englischen Version, unübersichtlicher gehts echt nimmer. Da muß man sich handschriftliche Notizen der gegenseitigen Abhängigkeiten machen, weil man die Hälfte schon wieder vergesse hat, wenn man sich endlich zum nächsten Punkt gehangelt hat. Gerade bei dieser Unzahl von Möglichkeiten sollte man doch auch ein halbwegs flüssig benutzbares UI erwarten?! Na, ich werde mich durchbeißen.
Wegen der IGMP-Sache, wenn da erst mal kein Weg 'reinführt, dann muß ich eben doch erst mal das blöde Fritzbox-Dingens behalten und mit den Abstürzen leben. Hat den Vorteil, daß ich den LC erst mal in Ruhe kennenlernen kann, und vielleicht kapiere ich auch irgendwann, was ich tun muß, damit ein auf ISDN ankommender Anruf am WLAN-VoIP-Telephon klingelt.
Am Manual stört mich einfach, daß es genauso wirr wie das UI scheint :( Da wäre schon irgendwas in der Art "LCOS für Anfänger" ganz nett. Aber auch da werde ich mich durchbeißen.
Alles in Allem habe ich einfach für so viel Geld etwas mehr Benutzbarkeit erwartet, und keine Kiste, an der man tagelang 'rumkonfiguriert, bis sie vielleicht irgendwann mal ansatzweise das tut, was sie soll. Aber anscheinend soll es so sein, zumindest hat das Ding das Potential, mein Wissen zu erweitern, zwangsläufig *g*
Viele Grüße
Ralph.
wenn zwei Bänder vorhanden sind, dann sind da auch zwei Funkmodule drin - außer, man spart am letzten cent und setzt nur einen Basisbandchip ein und schaltet das frontend um. _Das_ hätte ich in _der_ Preisklasse nicht erwartet, aber nun ja. Also doch wieder ein zusätzlicher Accesspoint, um beider Bänder abzudecken. Gnarf. Dabei wollte ich Strom sparen...
Was das Config-Dingens angeht, das ist einfach nur wirr, in der deutschen wie in der englischen Version, unübersichtlicher gehts echt nimmer. Da muß man sich handschriftliche Notizen der gegenseitigen Abhängigkeiten machen, weil man die Hälfte schon wieder vergesse hat, wenn man sich endlich zum nächsten Punkt gehangelt hat. Gerade bei dieser Unzahl von Möglichkeiten sollte man doch auch ein halbwegs flüssig benutzbares UI erwarten?! Na, ich werde mich durchbeißen.
Wegen der IGMP-Sache, wenn da erst mal kein Weg 'reinführt, dann muß ich eben doch erst mal das blöde Fritzbox-Dingens behalten und mit den Abstürzen leben. Hat den Vorteil, daß ich den LC erst mal in Ruhe kennenlernen kann, und vielleicht kapiere ich auch irgendwann, was ich tun muß, damit ein auf ISDN ankommender Anruf am WLAN-VoIP-Telephon klingelt.
Am Manual stört mich einfach, daß es genauso wirr wie das UI scheint :( Da wäre schon irgendwas in der Art "LCOS für Anfänger" ganz nett. Aber auch da werde ich mich durchbeißen.
Alles in Allem habe ich einfach für so viel Geld etwas mehr Benutzbarkeit erwartet, und keine Kiste, an der man tagelang 'rumkonfiguriert, bis sie vielleicht irgendwann mal ansatzweise das tut, was sie soll. Aber anscheinend soll es so sein, zumindest hat das Ding das Potential, mein Wissen zu erweitern, zwangsläufig *g*
Viele Grüße
Ralph.
Moin,
ist da im allgemeinen auch nur ein Modul drin, daß die Bänder nicht gleichzeitig kann. Und wenn
mehrere Module drin sind, dann wird das auch explizit so vermekrt (etwa in der Art 'zwei Dualband-Module').
Es mag einige andere Hersteller geben, die mit Dualband zwei echte Module meinen - das ist dann
aber eigentlich noch hirnverbrannter, wenn man ein Modul auf 2,4 GHz und das andere auf 5 GHz
beschränkt (jedes 5 GHz-fähige Modul kann auch auf 2,4 GHz betrieben werden - reine 5GHz-Module
haben sich am Markt nicht durchgesetzt). Wenn Du von LANCOM ein Gerät mit zwei Modulen kaufst,
kannst Du Dir bei beiden Modulen frei und unabhängig aussuchen, ob sie mit 5 oder 2.4 GHz laufen
sollen.
Gruß Alfred
Nein, da siehts Du etwas ziemlich falsch. Wen auf einem Client von "Dualband" die Rede ist, dannwenn zwei Bänder vorhanden sind, dann sind da auch zwei Funkmodule drin - außer, man spart am letzten cent und setzt nur einen Basisbandchip ein und schaltet das frontend um.
ist da im allgemeinen auch nur ein Modul drin, daß die Bänder nicht gleichzeitig kann. Und wenn
mehrere Module drin sind, dann wird das auch explizit so vermekrt (etwa in der Art 'zwei Dualband-Module').
Es mag einige andere Hersteller geben, die mit Dualband zwei echte Module meinen - das ist dann
aber eigentlich noch hirnverbrannter, wenn man ein Modul auf 2,4 GHz und das andere auf 5 GHz
beschränkt (jedes 5 GHz-fähige Modul kann auch auf 2,4 GHz betrieben werden - reine 5GHz-Module
haben sich am Markt nicht durchgesetzt). Wenn Du von LANCOM ein Gerät mit zwei Modulen kaufst,
kannst Du Dir bei beiden Modulen frei und unabhängig aussuchen, ob sie mit 5 oder 2.4 GHz laufen
sollen.
Gruß Alfred
Lancom investiert meiner Meinung nach zuviel Energie in VoIP, eine IGMP-Erweiterung für das LCOS sollte da zumindest zusätzlich drin sein.
IPTV wie von z.B. T-Home wird immer häufiger genutzt und da ist der Lancom trotz seiner vielen Features leider aussen vor. Ich hoffe nun schon bald 1 Jahr das ich das Gerät wieder sinnvoll nutzen kann und hoffe weiter. VoIP wird im Marktvolumen überschätzt, die Verkaufszahlen in diesem Bereich würden mich wirklich mal interessieren.
IPTV wie von z.B. T-Home wird immer häufiger genutzt und da ist der Lancom trotz seiner vielen Features leider aussen vor. Ich hoffe nun schon bald 1 Jahr das ich das Gerät wieder sinnvoll nutzen kann und hoffe weiter. VoIP wird im Marktvolumen überschätzt, die Verkaufszahlen in diesem Bereich würden mich wirklich mal interessieren.
VoIP hat sicher seine Berechtigung, und in dem Bereich können die Dinger schon eine ganze Menge; auch im IP-Sektor geht sehr viel, da denkt man, für IGMP würde sich sicher noch ein Platz finden. Gekauft habe ich das Ding dennoch, und ich werde es auch behalten - vielleicht kommt auch irgendwann der Tag, wo ich dann den Fritz endlich in Rente schicken kann.Routix hat geschrieben:Lancom investiert meiner Meinung nach zuviel Energie in VoIP, eine IGMP-Erweiterung für das LCOS sollte da zumindest zusätzlich drin sein.
IPTV wie von z.B. T-Home wird immer häufiger genutzt und da ist der Lancom trotz seiner vielen Features leider aussen vor. Ich hoffe nun schon bald 1 Jahr das ich das Gerät wieder sinnvoll nutzen kann und hoffe weiter. VoIP wird im Marktvolumen überschätzt, die Verkaufszahlen in diesem Bereich würden mich wirklich mal interessieren.
Viele Grüße
Ralph.
Moin,
die Produkte von LANOCM orientieren. Es ist zwar schön, daß es eine Reihe von Kunden gibt,
die sich auch zu Hause ein LANCOM hinstellen, aber im Vergleich zu den Geschäftskunden und -projekten
sind das doch recht überschaubare Stückzahlen. Den meisten Heimanwendern ist ein LANCOM aus
nachvollziehbaren Gründen zu teuer und wenn man einfach nur surfen will, tut's auch der
50-Euro-Router aus demBlödmarkt...).
Im Business-Bereich gibt's immer ein paar 'Trend-Themen', die von den Großen der Branche und
der Fachpresse gepusht werden, die dann die 'Entscheider' in ihre Ausschreibungen reinschreiben,
egal ob sie es nun wirklich so dringend brauchen oder nicht. Ob VoIP so ein Thema ist, will ich
nicht beurteilen, aber es ist nunmal ein Fakt, daß es die letzten 2..3 Jahre von Cisco und Konsorten
ziemlich massiv beworben worden ist. Mein persönlicher Eindruck ist, daß da inzwischen einfach
die Hype-Phase vorbei ist und die Leute jetzt etwas realistischer damit umgehen. VoIP wird
eingesetzt, die Kunden wissen langsam, was sie damit wirklich machen wollen und deshalb ist
in der 7.x ja soviel am VoIP geschraubt worden. Daß das noch nicht 100% fertig ist, sieht man
ja an den noch öfters auftretenden os_panics...wenn das VoIP-Thema irgendwann mal wirklich
rund ist, wird sicher auch wieder mehr Zeit für andere Dinge frei sein. Ob Multicast-Routing
dabei sein wird, kann ich nicht versprechen, das hängt davon ab, ob der genannte Kundenkreis
dafür Anwendungen entdeckt. Im Videokoferenzbereich könnte das irgendwann passieren,
vielleicht auch dann, wenn mehr Heimarbeiter mit VPN-Anbindung in die Firma einen VDSL-
Anschluß haben und den eben auch zum Fernsehen nutzen wollen. Dazu ist VDSL aber noch
zu wenig verbreitet...
Gruß Alfred
IPTV ist aber ein reines Consumerthema, und das ist nun einmal nicht der Markt, an dem sichLancom investiert meiner Meinung nach zuviel Energie in VoIP, eine IGMP-Erweiterung für das LCOS sollte da zumindest zusätzlich drin sein.
IPTV wie von z.B. T-Home wird immer häufiger genutzt und da ist der Lancom trotz seiner vielen Features leider aussen vor. Ich hoffe nun schon bald 1 Jahr das ich das Gerät wieder sinnvoll nutzen kann und hoffe weiter. VoIP wird im Marktvolumen überschätzt, die Verkaufszahlen in diesem Bereich würden mich wirklich mal interessieren.
die Produkte von LANOCM orientieren. Es ist zwar schön, daß es eine Reihe von Kunden gibt,
die sich auch zu Hause ein LANCOM hinstellen, aber im Vergleich zu den Geschäftskunden und -projekten
sind das doch recht überschaubare Stückzahlen. Den meisten Heimanwendern ist ein LANCOM aus
nachvollziehbaren Gründen zu teuer und wenn man einfach nur surfen will, tut's auch der
50-Euro-Router aus demBlödmarkt...).
Im Business-Bereich gibt's immer ein paar 'Trend-Themen', die von den Großen der Branche und
der Fachpresse gepusht werden, die dann die 'Entscheider' in ihre Ausschreibungen reinschreiben,
egal ob sie es nun wirklich so dringend brauchen oder nicht. Ob VoIP so ein Thema ist, will ich
nicht beurteilen, aber es ist nunmal ein Fakt, daß es die letzten 2..3 Jahre von Cisco und Konsorten
ziemlich massiv beworben worden ist. Mein persönlicher Eindruck ist, daß da inzwischen einfach
die Hype-Phase vorbei ist und die Leute jetzt etwas realistischer damit umgehen. VoIP wird
eingesetzt, die Kunden wissen langsam, was sie damit wirklich machen wollen und deshalb ist
in der 7.x ja soviel am VoIP geschraubt worden. Daß das noch nicht 100% fertig ist, sieht man
ja an den noch öfters auftretenden os_panics...wenn das VoIP-Thema irgendwann mal wirklich
rund ist, wird sicher auch wieder mehr Zeit für andere Dinge frei sein. Ob Multicast-Routing
dabei sein wird, kann ich nicht versprechen, das hängt davon ab, ob der genannte Kundenkreis
dafür Anwendungen entdeckt. Im Videokoferenzbereich könnte das irgendwann passieren,
vielleicht auch dann, wenn mehr Heimarbeiter mit VPN-Anbindung in die Firma einen VDSL-
Anschluß haben und den eben auch zum Fernsehen nutzen wollen. Dazu ist VDSL aber noch
zu wenig verbreitet...
Gruß Alfred
-
froeschi62
- Beiträge: 985
- Registriert: 13 Dez 2004, 10:44
-
Transcendence
- Beiträge: 144
- Registriert: 21 Okt 2006, 15:28
Wobei häufig insbesondere bei Selbständigen, aber auch bei anderen kleineren Unternehmen, am WAN-Anschluss für das Office auch noch das private LAN für die Privatwohnung im selben Haus, manchmal sogar in derselben Wohnung, mit dran hängt. Bei auffällig vielen unserer eigenen selbständigen Kunden (das sind dann meist Freiberufler mit Büros bis max 20 Mitarbeitern oder in Bürogemeinschaften, Praxen, Kanzleien) ist das z.B. der Fall. (Sobald es größer wird, ist das dagegen in der Regel kein Thema mehr.)
Und IPTV gibt es inzwischen ja nicht nur mit VDSL, sondern auch mit DSL 16000.
Bei dieser Nutzergruppe könnte Lancom seine Chancen auf einen ordentlichen Marktanteil durch entsprechende Weiterentwicklung sicher deutlich erhöhen. Ist halt die Frage, inwieweit aufgrund der Unternehmensstarategie daran Interesse besteht.
Grüße
T.
Und IPTV gibt es inzwischen ja nicht nur mit VDSL, sondern auch mit DSL 16000.
Bei dieser Nutzergruppe könnte Lancom seine Chancen auf einen ordentlichen Marktanteil durch entsprechende Weiterentwicklung sicher deutlich erhöhen. Ist halt die Frage, inwieweit aufgrund der Unternehmensstarategie daran Interesse besteht.
Grüße
T.
Hi dk5ras
Das Hauptproblem besteht ja darin, daß das LANCOM nicht weiß, was es mit den Multicasts machen soll, weshalb diese in der Routing-Tabelle über die Sperr-Route geblockt werden. Mit ein bischen policy-based Routing könntest du ggf. eine Lösung basteln, die zumindest mit einem IPTV-Receiver funktionieren könnte - ich sage extra: könnte.
Mein Vorschlag sieht so aus:
Erstelle zwei zusätzliche Multicast-Routen, mit verschiedenen Routing-Tags. Die erste zeigt auf die Internet-Verbindung, die zweite auf den IPTV-Receiver.
Also: angenommen deine Internetverbindung heißt INTERNET und dein Receiver habe die IP-Adresse 192.168.1.100. Dann müßtest du folgende Routen zusätzlich aufnehmen:
Achte darauf, daß an der Route zum Internet die Maskierung aktiviert ist!
Jetzt brauchst du noch zwei Firewallregeln, die die Multicasts auf die Routen verteilen:
vielleicht funktioniert das ja...
Gruß
Backslash
Ich weiß zwar nicht ob das wirklich funktionieren kann, aber versuch das Ganze dochmal mit ein paar Firewall-Tricks...ist denn IGMP wirklich sonst nahezu nirgends im Einsatz, nur bei IPTV? Das hätte ich so nicht erwartet. Jedenfalls, meine Forschungen nach einem Workaround gehen weiter
Das Hauptproblem besteht ja darin, daß das LANCOM nicht weiß, was es mit den Multicasts machen soll, weshalb diese in der Routing-Tabelle über die Sperr-Route geblockt werden. Mit ein bischen policy-based Routing könntest du ggf. eine Lösung basteln, die zumindest mit einem IPTV-Receiver funktionieren könnte - ich sage extra: könnte.
Mein Vorschlag sieht so aus:
Erstelle zwei zusätzliche Multicast-Routen, mit verschiedenen Routing-Tags. Die erste zeigt auf die Internet-Verbindung, die zweite auf den IPTV-Receiver.
Also: angenommen deine Internetverbindung heißt INTERNET und dein Receiver habe die IP-Adresse 192.168.1.100. Dann müßtest du folgende Routen zusätzlich aufnehmen:
Code: Alles auswählen
IP-address IP-netmask Rtg-Tag Router-name Distance masquerade
-----------------------------------------------------------------------------------
224.0.0.0 224.0.0.0 2 192.168.1.100 0 Off
224.0.0.0 224.0.0.0 1 INTERNET 0 on
Jetzt brauchst du noch zwei Firewallregeln, die die Multicasts auf die Routen verteilen:
Code: Alles auswählen
Name: SEND_MCST
Routing-Tag: 1
Aktion: übertagen
Quelle: 192.168.1.100 (IP des IPTV-Receivers)
Ziel: IP-Adresse 224.0.0.0 Netzmaske 224.0.0.0
Dienste: alle Dienste (oder auf das Protokoll IGMP beschränkt)
Name: RECEIVE_MCST
Routing-Tag: 2
Aktion: Gegenstelle INTERNET
Quelle: alle Stationen im lokalen Netz
Ziel: IP-Adresse 224.0.0.0 Netzmaske 224.0.0.0
Dienste: alle Dienste (oder auf die Protokolle UDP und IGMP beschränkt) Gruß
Backslash
-
froeschi62
- Beiträge: 985
- Registriert: 13 Dez 2004, 10:44
Hallo,
backslashs Vorschlag ist sehr interessant. Meine eigenen Versuche mit MC waren bisher erfolglos, vielleicht, weil ich mich darauf verlassen hatte, dass Multicasts von der Defaultroute erfasst werden, wenn sie nicht per Sperr-Route verboten sind.
Trotzdem, bevor ich es neu probiere, ein paar Anmerkungen zum zitierten Vorschlag, der nur zum ersten groben Funktionstest umgesetzt werden sollte. Für die laufende Nutzung als „Pseudo-Multicast-Proxy/Bridge“ wäre das ein Sicherheitsrisiko.
---------------------------------------------------------------------------------------------------------------------------------------------------
a) Routing
Multicast = 224/4 nicht 224/3. Deshalb gehört 240/4 weiterhin gesperrt.
Den link-local (224.0.0/24) MC-Traffic würde ich auch nicht pauschal ins Internet blasen, weder per Route noch per FW-Regel, denn dieser darf von wirklich multicast-fähigen Geräten nicht geroutet werden. IGMP (224.0.0.22/32) sollte über eine spezifische Route übertragen werden.
Darüber hinaus sind die Internetwork Control MCs (224.0.1.0/24) meistens für den ISP ebenfalls tabu.
Der admin scoped MC-Traffic (239/8) ist nicht pauschal zu behandeln, weil ISPs sich als "Organisation" definieren können und Multicasts innerhalb ihrer "Organisations"-Netzwerkgrenzen anbieten. T-Home IPTV fällt genau in diesen Bereich. Mit hoher Sicherheit auszuschließen ist der site-local-Anteil des "admin scoped" Bereichs (239.196.0.0/14, 239.200.0.0/13, 239.208.0.0/12, 239.224.0.0/12, 239.240.0.0/12). Mit vorsichtigem Ansatz würde ich 239/8 dichtmachen und nur für bekannte Quellen Passierscheine ausstellen (T-Home IPTV zum Beispiel, s. u.).
Ohne diese Einschränkungen wird die Firewall-Idee für Multicasts ad absurdum geführt: Wer möchte z. B. schon seine Novell SLP SA/DA -Pakete hinausposaunen (224.0.1.22 und 224.0.1.35)? Oder UPnP-Discoveries von allen WinXP-Stationen (239.255.255.250)? Oder die OSPF/EIGRP-Routing-Protokolle des größeren,privaten Firmennetzes? Wer billige Switches einsetzt, die Multicasts wie Broadcasts behandeln, z. B. den kleinen LANCOM Power-over-Ethernet-Switch, dem würde der Router sonst diesen Gefallen tun.
Deshalb mein modifizierter, aber immer noch sehr pauschaler Vorschlag für eine Routentabelle:
[code]
IP-address IP-netmask Rtg-Tag Router-name Distance masquerade
-----------------------------------------------------------------------------------
224.0.0.22 255.255.255.255 1 INTERNET 0 on ; TX IGMP
224.0.0.22 255.255.255.255 2 192.168.1.100 0 off ; RX IGMP
224.0.0.0 255.255.254.0 0 0.0.0.0 0 off
239.196.0.0 255.252.0.0 0 0.0.0.0 0 off
239.200.0.0 255.248.0.0 0 0.0.0.0 0 off
239.208.0.0 255.240.0.0 0 0.0.0.0 0 off
239.224.0.0 255.240.0.0 0 0.0.0.0 0 off
239.240.0.0 255.240.0.0 0 0.0.0.0 0 off
224.0.0.0 240.0.0.0 1 INTERNET 0 on ; TX allowed MC
224.0.0.0 240.0.0.0 2 192.168.1.100 0 off ; RX allowed MC
240.0.0.0 240.0.0.0 0 0.0.0.0 0 off
[/code]
---------------------------------------------------------------------------------------------------------------------------------------------------
b) Firewall
Darüber hinaus würde ich empfehlen, nicht jedes vom ISP ankommende MC-Paket nach innen durchzureichen (Firewall?!), denn die Quellen sind oft gut bekannt.
Also RECEIVE_MCST mit genauer spezifizierter Quelle anlegen!
Hier ein paar Beispiele, die ich in anderem Zusammenhang einmal herausgesucht habe:
IPTV Offers
Commercial offers are usually limited to the ISPs network boundaries.
Multicast addresses for IPTV in the ISP nets of „T-Home“ and „Hansenet“
http://www.ard-digital.de/index.php?id= ... nguageid=1
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.
Hansenet
- using GLOP multicasts 233.51.128.0/24
Arcor
- ??? Gut gehütetes Geheimnis von Arcor im Feldversuch in Kassel? Oder kennt jemand in der Runde die Arcor IPTV-Details?
Norwegian Television media.hiof.no
- using unofficial addresses from IANA reserved block
NRK3 (viewable with VLC) udp://@224.17.42.3
---------------------------------------------------------------------------------------------------------------------------------------------------
Und nun die Probe aufs Exempel.
Der Versuch einen Multicast-Stream zu buchen schlägt fehl. Das IGMP-Paket wird vom Router nicht wahrgenommen. „trace + ip-r firewall“ zeigt rein gar nichts.
Und von Router selbst aus getestet? „> ping 224.0.0.1“
[IP-Router] 2007/10/05 14:09:01,640
IP-Router Rx (intern, RtgTag: 0):
DstIP: 224.0.0.1, SrcIP: 10.1.8.1, Len: 84, DSCP: AF11 (10), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0e22, seq: 0x0000
no channel available => discard frame
Auch das Einstellen von DoS/IDS auf „übertragen“ hilft nicht weiter.
Ist beim LANCOM-IP-Stack die Reaktion auf ICMP-Echos an Broadcast-Adressen einfach generell abgeschaltet, vielleicht zum Schutz von Smurf-Attacken?
Schade, sehr schade, denn die LCOS-User stehen weiter ohne Workaround für die fehlende direkte Unterstützung von IGMP da.
Multicast nur für IPTV?
Nachdem mit VLC jeder einen Multicast-Videoserver betreiben kann, kommt man schon in Rechtfertigungsschwierigkeiten, wenn z. B. ein Mittelständler und treuer LANCOM-Kunde seine Webcasts für Schulungen auf Multicast umstellen will... Nur so als Beispiel.
Die Diskussion um Multicast-Unterstützung bei LCOS begrüße ich deshalb sehr, denn die jetzige Situation bedeutet für die Wiederverkäufer unter den Teilnehmern dieses Forums allmählich einen Wettbewerbsnachteil.
Gruß,
rougu
backslashs Vorschlag ist sehr interessant. Meine eigenen Versuche mit MC waren bisher erfolglos, vielleicht, weil ich mich darauf verlassen hatte, dass Multicasts von der Defaultroute erfasst werden, wenn sie nicht per Sperr-Route verboten sind.
Trotzdem, bevor ich es neu probiere, ein paar Anmerkungen zum zitierten Vorschlag, der nur zum ersten groben Funktionstest umgesetzt werden sollte. Für die laufende Nutzung als „Pseudo-Multicast-Proxy/Bridge“ wäre das ein Sicherheitsrisiko.
---------------------------------------------------------------------------------------------------------------------------------------------------
a) Routing
Multicast = 224/4 nicht 224/3. Deshalb gehört 240/4 weiterhin gesperrt.
Den link-local (224.0.0/24) MC-Traffic würde ich auch nicht pauschal ins Internet blasen, weder per Route noch per FW-Regel, denn dieser darf von wirklich multicast-fähigen Geräten nicht geroutet werden. IGMP (224.0.0.22/32) sollte über eine spezifische Route übertragen werden.
Darüber hinaus sind die Internetwork Control MCs (224.0.1.0/24) meistens für den ISP ebenfalls tabu.
Der admin scoped MC-Traffic (239/8) ist nicht pauschal zu behandeln, weil ISPs sich als "Organisation" definieren können und Multicasts innerhalb ihrer "Organisations"-Netzwerkgrenzen anbieten. T-Home IPTV fällt genau in diesen Bereich. Mit hoher Sicherheit auszuschließen ist der site-local-Anteil des "admin scoped" Bereichs (239.196.0.0/14, 239.200.0.0/13, 239.208.0.0/12, 239.224.0.0/12, 239.240.0.0/12). Mit vorsichtigem Ansatz würde ich 239/8 dichtmachen und nur für bekannte Quellen Passierscheine ausstellen (T-Home IPTV zum Beispiel, s. u.).
Ohne diese Einschränkungen wird die Firewall-Idee für Multicasts ad absurdum geführt: Wer möchte z. B. schon seine Novell SLP SA/DA -Pakete hinausposaunen (224.0.1.22 und 224.0.1.35)? Oder UPnP-Discoveries von allen WinXP-Stationen (239.255.255.250)? Oder die OSPF/EIGRP-Routing-Protokolle des größeren,privaten Firmennetzes? Wer billige Switches einsetzt, die Multicasts wie Broadcasts behandeln, z. B. den kleinen LANCOM Power-over-Ethernet-Switch, dem würde der Router sonst diesen Gefallen tun.
Deshalb mein modifizierter, aber immer noch sehr pauschaler Vorschlag für eine Routentabelle:
[code]
IP-address IP-netmask Rtg-Tag Router-name Distance masquerade
-----------------------------------------------------------------------------------
224.0.0.22 255.255.255.255 1 INTERNET 0 on ; TX IGMP
224.0.0.22 255.255.255.255 2 192.168.1.100 0 off ; RX IGMP
224.0.0.0 255.255.254.0 0 0.0.0.0 0 off
239.196.0.0 255.252.0.0 0 0.0.0.0 0 off
239.200.0.0 255.248.0.0 0 0.0.0.0 0 off
239.208.0.0 255.240.0.0 0 0.0.0.0 0 off
239.224.0.0 255.240.0.0 0 0.0.0.0 0 off
239.240.0.0 255.240.0.0 0 0.0.0.0 0 off
224.0.0.0 240.0.0.0 1 INTERNET 0 on ; TX allowed MC
224.0.0.0 240.0.0.0 2 192.168.1.100 0 off ; RX allowed MC
240.0.0.0 240.0.0.0 0 0.0.0.0 0 off
[/code]
---------------------------------------------------------------------------------------------------------------------------------------------------
b) Firewall
Darüber hinaus würde ich empfehlen, nicht jedes vom ISP ankommende MC-Paket nach innen durchzureichen (Firewall?!), denn die Quellen sind oft gut bekannt.
Also RECEIVE_MCST mit genauer spezifizierter Quelle anlegen!
Hier ein paar Beispiele, die ich in anderem Zusammenhang einmal herausgesucht habe:
IPTV Offers
Commercial offers are usually limited to the ISPs network boundaries.
Multicast addresses for IPTV in the ISP nets of „T-Home“ and „Hansenet“
http://www.ard-digital.de/index.php?id= ... nguageid=1
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.
Hansenet
- using GLOP multicasts 233.51.128.0/24
Arcor
- ??? Gut gehütetes Geheimnis von Arcor im Feldversuch in Kassel? Oder kennt jemand in der Runde die Arcor IPTV-Details?
Norwegian Television media.hiof.no
- using unofficial addresses from IANA reserved block
NRK3 (viewable with VLC) udp://@224.17.42.3
---------------------------------------------------------------------------------------------------------------------------------------------------
Und nun die Probe aufs Exempel.
Der Versuch einen Multicast-Stream zu buchen schlägt fehl. Das IGMP-Paket wird vom Router nicht wahrgenommen. „trace + ip-r firewall“ zeigt rein gar nichts.
Und von Router selbst aus getestet? „> ping 224.0.0.1“
[IP-Router] 2007/10/05 14:09:01,640
IP-Router Rx (intern, RtgTag: 0):
DstIP: 224.0.0.1, SrcIP: 10.1.8.1, Len: 84, DSCP: AF11 (10), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0e22, seq: 0x0000
no channel available => discard frame
Auch das Einstellen von DoS/IDS auf „übertragen“ hilft nicht weiter.
Ist beim LANCOM-IP-Stack die Reaktion auf ICMP-Echos an Broadcast-Adressen einfach generell abgeschaltet, vielleicht zum Schutz von Smurf-Attacken?
Schade, sehr schade, denn die LCOS-User stehen weiter ohne Workaround für die fehlende direkte Unterstützung von IGMP da.
Multicast nur für IPTV?
Nachdem mit VLC jeder einen Multicast-Videoserver betreiben kann, kommt man schon in Rechtfertigungsschwierigkeiten, wenn z. B. ein Mittelständler und treuer LANCOM-Kunde seine Webcasts für Schulungen auf Multicast umstellen will... Nur so als Beispiel.
Die Diskussion um Multicast-Unterstützung bei LCOS begrüße ich deshalb sehr, denn die jetzige Situation bedeutet für die Wiederverkäufer unter den Teilnehmern dieses Forums allmählich einen Wettbewerbsnachteil.
Gruß,
rougu
Zuletzt geändert von Rougu am 13 Okt 2007, 08:14, insgesamt 1-mal geändert.