- √ - Fritzbox wiederholt bei IP Routing alle GAs !!!!!

[Sensemann]

Hallo Zusammen,

habe den gleichen Mist, die KNX Multicast Pakete werden vom Router als Kopie zurück ins LAN gesendet. Bei mir ist einSpeedPort Pro Plus der Telekom schuld.
Firmware-Version:
120141.4.1.007.1
Datum der Firmware:
21-05-21
Habe noch nicht geschaut ob es zu dem Router auch einen Thream im Forum gibt, mache ich später noch. Habe den Speedport jetzt hinter einen managable CISCO Switch gesteckt bei dem ich für jeden Port einzeln das Multicast Forwarding deaktiveren kann. Dann stört der Speedport nicht mehr mein KNX/IP im LAN.
Dann geht aber nicht mehr KNX/IP Multicast im WLAN da ich WLAN über den Speedport nutze. Kann also z.B. nur KNX/IP über Tunnel Protokoll mit meinem ABB KNX/IP Router sprechen.

Habe ein Ticket bei der Telekom aufgemacht und bin schon so weite gekommen das ich einem Mitarbeiter aus dieser Abteilung einen Mitschnitt (LAN Capture) des Speedport schicken darf, damit er das an den Hersteller meldet.
Deutsche Telekom Service GmbH
Technischer Kundenservice
Genius-Anschluss

Er meinte die haben schon mehrere "KundenAnligen" so über den Hersteller als Firmwarefix bearbeitet.

Bin mal gespannt ob sich da etwas tut.

Zu Begin meines Bauvorhabens war ich über das WLAN meines Nachbarn ans Internet angeschlossen und hatte erst mal keine Probleme mit Multicast.
Als ich dann meine AVM FRITZ!Box 7490 in Betrieb genommen habe, hatte ich meine ich auch das Problem. Mittlerweile macht die keine Probleme mehr, könnte aber daran liegen dass ich sie im "Client-Modus" hinter dem Speedport betreibe und sie sich somit nicht als echter Router emfindet...
Hatte ich zu der Zeit nicht weiter untersucht sonder da nur den Thread hier gefunden. Wußte mir aber nicht so schnell zu helfen und hatte auch nicht viel Zeit für die Analyse..

Danke für das Forum hier und die vielen Menschen die hier beitragen, eine echte Hilfe !!

Grüße
Jens

[saft6luck]

Wenn man ein bisschen IP kann ja auch kein Hexenwerk, muss ja kein 500 EUR Router sein, Vlans können mittlerweile schon fast die Switches aus der 10€ Grabbelkiste, und/oder einen halbwegs brauchbaren 50€ Router(Acccesspoint,..) auf dem man das NAT abschalten kann (WAN->Heimnetz, LAN->KNX) oder OpenWRT draufbekommt..

Ja, VLAN kann (könnte?) das sehr einfach machen, wenn einzelne "KNX-Geräte" (z.B. eibPC etc.), die z.B. zusätzlich das Internet brauchen, auch VLAN Unterstützung auf ihrem einzigen LAN-Port anbieten würden.
So aber muss man auf einen zusätzlichen Router ausweichen ... meist wieder ein Stromverbraucher mehr.

[tbi]

Hallo Klaus,

das geht schon. Bei AVM haben sie es schnell vestanden und dann behoben. Sie haben nur eben schon viele FB Versionen im Feld deshalb gab es diesen Thread. Nun sind aber alle FBs ok.

Ein DSL Modem oder eben ein CPE bei FTTH muß eben für.die Provider so manche Sonderlocke für IPTV machen. Der DSLAM oder MSAN ist hier ein Bordergateway. Das ist eben kein homogenes Netz.

Ich denke aber die meisten aktuellen CPEs also DSL Modems können nun IGMP.

Viele Grüße

Tbi

[drdotti]

Hallo Leute,

danke für eure Antworten.
Aus meiner Sicht ist das auch ein FB Problem, ich habe mehr als 100 Netzwerkteilnehmer verschiedenster Hesteller und keiner von denen ist so unverschämt und verdoppelt einfach Packete auf dem gleichen Port.

Mal schauen was ich da mit meinen FTTH Provider basteln kann. Ich hoffe ja immer noch, dass die FB entweder keine Probleme macht, oder dass ich diese eventuell durch einen fli4l oder anderen Linux Router erstezen kann.

mfg

Klaus D.

[Gaston]

Ich hatte auf die AW ja schon fast angstvoll gewartet

Ich bin doch gar nicht so böse wie Ihr immer denkt

Aber da sind wir uns einig..

Sag Ich doch

Was ich sagen wollte: AVM baut einen Workaround für die IP-TV boxen, für 99,9% eine Problemlösung, durchaus verständlich, ob nun technisch richtig oder nicht..

Absolut korrekt. Nur hätte Ich es nicht so gemacht dass es alle Multicasts betrifft.

Den Anwender interessiert das nicht..

naja, spätestens wenn'0s Probleme mit anderen Anwendungen gibt schon.

Fazit: Wenn in den entscheidenden Gremien usw. z.B. der Konnex solche Leute wie Gaston wären, müsste so ein Mist eigentlich nicht sein..

Danke für die Blumen. Vieleicht sollte Ich mich bei der Konnex als Berater melden

Gruss,
Gaston

[makki]

Ich hatte auf die AW ja schon fast angstvoll gewartet

Fazit: Problem=FB und KNXnet/IP nicht sauber spezifiziert

Aber da sind wir uns einig..
Was ich sagen wollte: AVM baut einen Workaround für die IP-TV boxen, für 99,9% eine Problemlösung, durchaus verständlich, ob nun technisch richtig oder nicht.. Den Anwender interessiert das nicht.. Natürlich ist das Käse, aber erklär das mal x T-Offline IP-TV Kunden am Telefon, das nur ihre Box von der Bundespost grobe sch** baut.. als AVM, ich verstehs und hätte es vermutlich nicht anders gemacht (die 4 von den zigtausend, die halt auch gerne KNX ohne Telegrammwiederholungen hätten, naja.. Einzelschicksal, so bitter es klingt)

(meine T300-irgendwas, hatte ein Windows CE oder so, die hat das erste Multicast-Packerl halt mal verschluckt, hmm, schonmal ein Windows mit einem nach RFC halbwegs funktionierenden IP-Stack gesehen? )

Fazit: Wenn in den entscheidenden Gremien usw. z.B. der Konnex solche Leute wie Gaston wären, müsste so ein Mist eigentlich nicht sein..
Wiegesagt: dieses Problem ist IMHO mehrschichtig..

Makki

[Gaston]

Das "Problem" ist - ganz nüchtern betrachtet - vielschichtig

Ja, ja das Multicast RFC. In meinen Augen eins der miesen RFCs.

Eins vorweg: Makki hat nicht unrecht mit dem was er schreibt, rein formal muss ein Multicast Empfänger (nicht Sender!) IGMP können. Eigentlich ist das aber m.E. ein Fehler im RFC und steht im Gegensatz zum RFC selbst. Es ist eigentlich nicht unbeding nötig wurde aber so reingeschrieben weil das Beschreiben der Ausnahmen das RFC zu Komplex machen würde.

Allerdings hat das mit dem Problem mit der FB nichts direkt zu tun. Hier ist liegt die FB eindeutig falsch. Wenn der KNXRouter sein Paket richtig aufbaut sogar doppelt falsch.

Denn wenn der KNX/IP-Router sein Paket richtig aufbaut dann weis er laut RFC auch dass er kein IGMP benötigt. Das Problem dabei ist dass die KNX.org hätte sagen müssen "IGMP muss" oder "IGMP nur im lokalen Netz". So wie es in den Specs steht können u.U. KNX/IP-Router unter sich inkompatibel sein.

Es ist noch viel schlimmer:
- die "IP-Router" (KNXnet/IP Gateway würde jemand mit wissen über die ISO/OSI-Layer dazu sagen) können garkein IGMP.. nicht RFC-konform..

Jop, aber das ist KNX nicht alleine. Lokales IGMP ohne IGMP ist ein "defakto-standard" der aus den oben genannten gründen nicht in den RFCs steht. Wenn richtig gemacht steht dies auch nicht im technischen Gegensatz zu den RFCs.

Für den KNX'ler ein perfektes Produkt, für den Netzwerker ein purer Störsender, Problem.. Vielleicht sollte man da mal drüber reden

Das Fehlen des IGMPs macht Ihn mit Sicherheit nicht zu einem Störsender. Das Netz müsste sich nähmlich auf das Multicast Paket verhalten wie ein Netz ohne Multicastrouter.

-> Der Fehler liegt hier IMHO beiderseits: AVM baut (verständlicherweise) Workarounds für crap und der andere crap (KNXnet/IP) fällt dabei auf die Nase, weil man die RFC offenbar nicht gelesen hat (Tipp vom Küken z.B., falls jemand mitliest: Der Routing-Counter im KNX ist nicht KNX-Gottgegeben sondern man sollte halt den von der grossen Mutter verwenden: IP)

Meine KNX/IP-Router haben einen TTL von 1 und sollten somit auf keinen Fall geroutet werden. Aber auch ansonsten ist hier nur AVM am dilema Schuld, denn ohne IGMP hat dieser nichts zu forwarden.

AVM ist eindeutig schuld an der Wiederholung:

• kein forwarding wenn es keinen IGMP Eintrag gibt
• kein reflective forwarding auf das gleiche Netz
• wenn Ich einen nicht RFC-Konformen Fix für einen meiner Kunden einsetze dann mache ich diesen so restriktiv wie möglich (z.B. nur für eine bestimmte Multicastadresse) und er Option verwaltbar.

Fazit: Problem=FB und KNXnet/IP nicht sauber spezifiziert

Das sind meine 5cts zu der Thematik.

Gruss,
Gaston

[makki]

Lt tbi in Post #78 hier hat die 7390 das "Feature" nicht..

..
Wäre echt nicht schön, wenn ich da noch mal einen Router zwischen schalten müsste um die Multicast Telegramme von der FritzBox fern zuhalten.

Wenn auch nicht ganz der Heimnetzwerker-weg-des-geringsten-Widerstands: halte ich es trotzdem für eine verdammt gute Idee, das Heimnetzwerk mit dem ganzen Medien-gedöns (das auch noch explosionsartig zunimmt) vom "KNX-LAN" zu segmentieren! Das spart einem auch zukünftig solch unangenehme Überraschungen oder das eben jeder rümpftel mit einer App mal kurz..
Wenn man ein bisschen IP kann ja auch kein Hexenwerk, muss ja kein 500 EUR Router sein, Vlans können mittlerweile schon fast die Switches aus der 10€ Grabbelkiste, und/oder einen halbwegs brauchbaren 50€ Router(Acccesspoint,..) auf dem man das NAT abschalten kann (WAN->Heimnetz, LAN->KNX) oder OpenWRT draufbekommt..

Nur meine 5ct..

Makki

[drdotti]

Hallo Leute,

auch ich hatte vor eingen Jahren mal Probleme mit AVM Produkten und KNX/IP Routern. Sobald ein AVM Produkt am Netzwerk angeschlossen war wurden alle Multicast Telegramme verdoppelt. Ich hab dann alle AVM Produkte aus meinem Netz verpannt, da mir der AVM Support damals nicht wirklich geholfen hat.

Ich wollte jetzt mal wissen, on schon jemand mal die "FRITZ!Box Fon WLAN 7390" getestet hat?
Ich bekomme bald FTTH und mus hier die 7390 nutzen. Wäre echt nicht schön, wenn ich da noch mal einen Router zwischen schalten müsste um die Multicast Telegramme von der FritzBox fern zuhalten.

mfg


Klaus D.

[makki]

Wenns ein "IP-Router" (mich schüttelt es ja immernoch jedesmal, wenn ich das Wort nur schreibe, weil es ist kein "Router" sondern für mich ein KNX/IP-Gateway) ist es klar: egal woher, er schickts raus, die FB wiederholt es (aus genannten Workaround-gründen, ich habe das IP-TV der Bundespost wirklich mal selbst gehabt und sehr im Detail zerlegt, weiss daher auch warum dem nun so ist, aber das spielt ja hier keine Rolle..Es erklärt nur den Workaround von AVM)

Makki

[flotzi]

Sehr gute Beschreibung des Desasters !

Ich "stamme" auch aus der EDV.
Deswegen habe ich wie in der Skizze beschrieben verkabelt um direkte Punkt zu Punkt Verbindungen zu ermöglichen zwischen IP-Router und Laptop über den Switch.

Die doppelten GAs treten in meinem Umfeld jedoch auch beim KNXnet/IP Tunneling Buszugriff in der ETS3 und 4 beim Gruppenmonitor und Programmieren auf.

Dafür habe ich bisher keine Erklärung.

[drego]

Im Detail ist das pure Freakshow und kann sehr schnell sehr kompliziert werden, genau deshalb bin ich da auch verdammt vorsichtig und schreibe immer dazu, ob ich KNXnet/IP Tunneling (UDP, Punkt-zu-Punkt, einfach, geht immer&überall wie ein Ping) oder KNXnet/IP Routing (auch UDP, aber Multicast, das könnte funktionieren, muss aber deswegen noch lange nicht)

Genau so seh ich das auch, als Informatiker, der sich mit OSI Schichten leider schon oft beschäftigten musste

[makki]

Das "Problem" ist - ganz nüchtern betrachtet - vielschichtig

ich vermute folgendes: Die alte Fritzbox kann gar kein IGMP. ..

Es ist noch viel schlimmer:
- die "IP-Router" (KNXnet/IP Gateway würde jemand mit wissen über die ISO/OSI-Layer dazu sagen) können garkein IGMP.. nicht RFC-konform.. Wie auch, da steckt ein uralter 8Bit uC drin, beim KNX-konformitätstest wird zwar perfekt geprüft obs dem KNX-Standard entspricht - sehr gut - jedoch leider nahe null obs auch den anderen involvierten Standards (IEEE? IETF?) entspricht.. Für den KNX'ler ein perfektes Produkt, für den Netzwerker ein purer Störsender, Problem.. Vielleicht sollte man da mal drüber reden

- gewisse, beliebte Produkte die meinen KNXnet/IP zu können, sind ebenfalls nicht mächtig IGMP richtig zu sprechen. nicht RFC-konform.. Problem..

- Die Fritzboxen mit dem "Bug" (der zwar einer ist, aber..) tun nur das um 1000:1 Kunden glücklich zu machen: damit die ebenfalls nicht RFC-konformen IP-TV-Boxen der Bundespost, äh T-offline, äh T-Home funzen..
Ich hatte sowas ja mal "echt", mit einem handelsüblichen Cisco-Router in der 1k€-Klasse - statt dem Speedshit/Fritzi - war das nicht ans laufen zu bekommen.. Traurig..

-> Der Fehler liegt hier IMHO beiderseits: AVM baut (verständlicherweise) Workarounds für crap und der andere crap (KNXnet/IP) fällt dabei auf die Nase, weil man die RFC offenbar nicht gelesen hat (Tipp vom Küken z.B., falls jemand mitliest: Der Routing-Counter im KNX ist nicht KNX-Gottgegeben sondern man sollte halt den von der grossen Mutter verwenden: IP)

Mein Fazit: Multicast ist insgesamt ein totales Beta-Experiment, keiner beherrscht das wirklich (ich darf das als Ex-MCSE und fast-CCIE behaupten, glaube ich) ist sehr schade das sich KNXnet/IP Routing diesen Malus anhaftet, aber nun ist es so..

Im Detail ist das pure Freakshow und kann sehr schnell sehr kompliziert werden, genau deshalb bin ich da auch verdammt vorsichtig und schreibe immer dazu, ob ich KNXnet/IP Tunneling (UDP, Punkt-zu-Punkt, einfach, geht immer&überall wie ein Ping) oder KNXnet/IP Routing (auch UDP, aber Multicast, das könnte funktionieren, muss aber deswegen noch lange nicht)

Makki

[Joggi2222]

Hi,
wie gesagt, ich hatte das Problem und nachdem ich nachvollzogen hatte, was ich alles eingestellt habe bzw. geändert habe, dann stellte ich es zurück und ich wusste den Grund -

War am Anfang schon kurz geschockt und dachte, was ist jetzt passiert. Aber halb so wild im Nachhinein.

Schönen Abend
Joggi

[tbi]

Ja Joggi,

ich hatte da noch an die FB als Router oder als Switch eingesetzt gedacht.

Denn als Router bridged er zwischen LAN und WAN. Bei IGMP würde er da auch ggf. doppeln.

Es gibt also viele Möglichkeiten sich auf Kreuz zu legen, mal von den Fehlern in den Geräten abgesehen

Viele Grüsse

Tbi