Problem mit KNXnet/IP Router nach Update Fritz.Box 7490 auf FRITZ!OS 6.50

[makki]

Oder den HS einfach per Tunneling statt Multicast kommunizieren lassen...?
Ich bin nämlich auf diverse Phänomene im Zusammenhang mit Multicast gestoßen - z.B. auch bei der ETS4 (die ETS kann nix dafür, mein Netzwerk war Schuld).
IP-Multicast ist nunmal was es ist: Unzuverlässig, da i.d.R. UDP-basiert. Und das merkt man immer mal wieder im KNX-Bereich - Telegramme gehen verloren, ETS-Programmierung scheitert usw...

Aua, es wird immer schlimmer!
KNXnet/IP "Routing" (ich setze das bewusst in "", weil es nix mit IP Routing zu tun hat..) ist ebenso wie KNXnet/IP Tunneling UDP, das eine eben Multicast, das andere Unicast.
Multicast ist ein graus und nur an wenigen Stellen sinnvoll, bestimmt nicht bei 9.6kBit KNX über 10-1000Mbit-Strippen, da gebe ich dir Recht.
Der HS kann übrigens kein KNXnet/IP Tunneling, also stellt sich die Frage da garnicht..
DHCP ist etwas für laien? Nein, es ist umgekehrt, halbwissende Laien verwenden statische IP's Sorry, da bleibe ich bei.
Sortier mal bitte die 7 ISO/OSI-Layer, bevor wir hier über Unicast, Multicast, TCP, UDP, Switch, ... sprechen, weil das eine hat (ich wiederhole mich) mit dem anderen nunmal rein garnix zu tun..


Weiter im Text:
- der Aussage "USB-Schnittstelle" will ich deutlich widersprechen, die sind einfach Design-mässig schon Elektro-Schrott, ich würde IP immer den Vorzug geben (sofern es richtig gemacht ist!) Ebenso die FT1.2, mir sind zwei am HS verreckt, das nervt.
- zur Fritzbox - ich weiss nicht ob sie die Marotte noch hat, aber die wiederholt halt IGMP (was wiederum der HS auch nur zu 30% kann) und das killt die Sache.. Ein Trauerspiel..

- Getrennte Netze: Juhu! (fast) alle Probleme lösen sich in Luft auf, wers braucht und 3671/UDP mit ner Fritzbox ins Inet durchalten will ist - mit Verlaub - eh irre..
Goto VPN, Netz-Segmentierung; an einer Fritzbox - Bugs hin oder her - hat ein KNX nichts zu suchen..

Meine weiteren 5ct.

Makki

[makki]

Achso, noch zum offenbar weit verbreiteten Irrglauben eine USB oder FT1.2 am HS wäre besser als IP:
damit sind Telegramm-Verluste bei höherer (Standardkonformer!) Buslast vorprogrammiert, den die können das im Gegensatz zur IP-Schnittstelle schlicht und ergreifend nicht (wer zweifelt, dem liefere ich gerne Messprotokolle mit 20-50 tps, wo es abk**.. mit HS, eibd/knxd und ETS - alles nativ ohne VM!)
Wenn man sich natürlich mit 30% des Potentials von KNX zufrieden gibt, geht das vielleicht.
Ansonsten IP - ist nur eben anstregend und kein Job für Fritzi

Makki

[gaert]

Zum Thema USB:
Ganz meiner Meinung!

Zum Thema "Tunneling" (so heißt das nunmal in der KNX-Welt...):
Du hast schon recht - ist auch UDP. Allerdings "bidirektional", sprich: Der IP-Router (KNX) ACKed ein vom "Client" übermitteltes Telegramm, usw.! Das ist der entscheidende Unterschied zum Multicast (in diesem Fall).

Zum Thema generell:
Du wirfst "tolle" Begriffe in die Welt - mehr aber auch nicht. Für Laien ließt sich das bestimmt unglaublich professionell - ich kann allerdings keinen Inhalt in Deiner Aussage erkennen. Wir können uns gerne (an anderer Stelle) detailiert über Protokolle etc. auslassen, aber hier ging es ja um etwas ganz anderes...
Nix für ungut, aber programmiere Du doch erstmal einen KNX/IP-Stack - dann sind wir auf Augenhöhe

[MatthiasS]

Ich bleibe dabei: es gibt am HS nichts stabileres und unkomplizierteres als eine USB-Schnittstelle. Funktioniert sogar mit Fritzbox.

[DiMa]

aber die [Fritzbox] wiederholt halt IGMP (was wiederum der HS auch nur zu 30% kann) und das killt die Sache.. Ein Trauerspiel..

Könntest du diesen Satz evtl. in eine standardkonforme Sprache übersetzen, so dass man einen Eindruck gewinnen kann, was du überhaupt sagen willst? Mir persönlich ist weder klar, wie man IGMP (geraten: snooping) "wiederholt", noch was man sich unter "30% IGMP" vorstellen soll.

[Menig]

ich bleibe ebenfalls bei meiner Aussage:
ein korrekter physikalischer Netzwerkaufbau mit Produkten die sich gültigen Normen / Protokolle halten.... und natürlich die saubere Konfiguration dieser Komponenten macht halt einfach Sinn....

Die FritzBox entspricht dieser Anforderung nicht.... macht aber als "vorgeschaltetes Gerät" einfach für Privatkunden Sinn da die tollen Supporthotlines der DTAG etc. das Teil halt im Supportkatalog haben... komm denen mal mit "echten" Netzwerkroutern....
da verkacken die nunmal sofort....

Makki:
Und zu einem sauberen Netzwerkaufbau mit vernünftiger Hardware gehört in meinen Augen auch eine saubere Segmentierung / Trennung.....
Und das macht man eben NICHT über die FritzBox.... keine Ahnung wie Du das in meinen Text reininterpretiert hast...

[MarkusS]

Könntest du diesen Satz evtl. in eine standardkonforme Sprache übersetzen, so dass man einen Eindruck gewinnen kann, was du überhaupt sagen willst? Mir persönlich ist weder klar, wie man IGMP (geraten: snooping) "wiederholt", noch was man sich unter "30% IGMP" vorstellen soll.

Ich bin sicher dass die Forensuche dazu einiges findet. Das Thema ist alles andere als neu und wurde hier über die Jahre mehrfach diskutiert.

AVM hat offensichtlich eine besondere Liebe zu Multicast und bringt immer wieder mal Firmwares mit denen KNXnet/IP Routing nicht funktioniert. Wenn man das dem "Support" in Berlin lange genug erklärt und mit Netzwerkmitschnitten zeigt was da schief läuft dann haben die bislang immer ein Einsehen gehabt und das repariert.

Wenn man Fritzbox und Multicast googelt kriegt man unzählige Treffer, meistens irgendwelche Leute deren lurchiges Telekom-IPTV nicht sauber tut.

Diese Fritzboxen sind wie Cisco. Können alles aber nichts richtig und der Rest sind Bugs.

[makki]

Makki:
Und zu einem sauberen Netzwerkaufbau mit vernünftiger Hardware gehört in meinen Augen auch eine saubere Segmentierung / Trennung.....
Und das macht man eben NICHT über die FritzBox.... keine Ahnung wie Du das in meinen Text reininterpretiert hast...

Dem widerspreche ich doch garnicht ?!

Aber danach sind wir wieder beim Kernproblem: Das Protokolle verschiedener Layer verwechselt werden: IGMP (bitte einfach Wikipedia benutzen) ist konträr zu "snooping" das genau das versucht: dumm zu simulieren.
Die Fritzbox und jeder halbswegs brauchbare Switch kann IGMP v2/3 übrigens, nur halt der HS und die "KNXnet/IP Router" nicht, was an HS und dem halbgaren KNX-Standard liegt.

P.S.: MatthiasS das mit dem USB-Interface probieren wir einfach mal aus, wieviele Telegramme das bei 25-50 tps (lt. Std auf TP1 erlaubt) unerkannt verliert
Das Haupt-Problem in "kleinen" Umgebungen ist aber ein anderes: die SS am HS (USB, FT1.2) können schlicht kein (i)ACK schicken, damit hat man durch 3x Wiederholung die 3x Buslast.

Grüsse Makki

[crettig]

Auch wenn der Betrieb von Homeserver und KNXnet/IP Router an einer FritzBox offenbar aus den verschiedenen hier erörterten Gründen nicht optimal ist hat die Konstellation doch bei mir die letzten Jahre ohne Probleme funktioniert.

Daher habe ich auf jeden Fall eine Support Anfrage an AVM gestellt und das Problem geschildert. AVM hat schon (am 26. Dezember !) mit einer persönlichen Mail von einem Supporter reagiert und weitere Informationen und Daten angefordert. Diese habe ich gerade zusammengestellt an den AVM-Supporter weitergleitet ... mal sehen was nun passiert.

Auf jeden Fall dürfen HS und KNXnet/IP Router erst mal bis auf Weiteres über den externen Switch kommunizieren.

Ich hoffe, dass der Beitrag hier dazu führt das andere Leute nicht wie ich stundenlang nach dem Fehler suchen sondern über das Forum hier gleich erfahren, dass das FritzOS 6.50 in der Sache, zumindest in bestimmten Konstellationen, ein Problem hat. Es gab ja zumindest schon einige die dies bestätigt haben.

[crettig]

Hat jemand HS und KNXnet/IP Router erfolgreich an der Fritzbox unter FritzOS 6.50 laufen?
(...also HS und KNXnet/IP Router an den LAN-Buchsen der FritzBox angeschlossen)

[makki]

Zum Thema USB:
Ganz meiner Meinung!

Zum Thema "Tunneling" (so heißt das nunmal in der KNX-Welt...):
Du hast schon recht - ist auch UDP. Allerdings "bidirektional", sprich: Der IP-Router (KNX) ACKed ein vom "Client" übermitteltes Telegramm, usw.! Das ist der entscheidende Unterschied zum Multicast (in diesem Fall).

Quatsch, sorry.
Woher nimmst Du die Erkenntniss, das KNXnet/IP Tunneling Telegramme "ACKed" ?
Im KNX-Standard steht das jedenfalls nicht. Technisch ist das auch auf TP1 nicht möglich, so mal rein vom Timing her..
Weil das bekommt ein "guter" grad mal im lokalen uC hin, bestimmt nicht via LAN..

Zum Thema generell:
Du wirfst "tolle" Begriffe in die Welt - mehr aber auch nicht. Für Laien ließt sich das bestimmt unglaublich professionell - ich kann allerdings keinen Inhalt in Deiner Aussage erkennen. Wir können uns gerne (an anderer Stelle) detailiert über Protokolle etc. auslassen, aber hier ging es ja um etwas ganz anderes...
Nix für ungut, aber programmiere Du doch erstmal einen KNX/IP-Stack - dann sind wir auf Augenhöhe

Was willst du mir sagen? Das Du doller bist? Ok.. Kann sein.
Aber ich weiss - unter uns wer nen KNX-Stack geschrieben hat, ich zähle mich selbst dummerweise dazu Ok ?

Makki

[makki]

Auch wenn der Betrieb von Homeserver und KNXnet/IP Router an einer FritzBox offenbar aus den verschiedenen hier erörterten Gründen nicht optimal ist hat die Konstellation doch bei mir die letzten Jahre ohne Probleme funktioniert.

Um zum Thema zurückzukommen (sorry, den Rest konnte ich mir nicht verkneifen):

Natürlich *sollte* das funktionieren, tut es aber oft nicht, weil sich weder HS noch KNXnet/IP-Standard oder Fritzbox so wirklich an die RFC halten.
KNXnet/IP macht was es will, der HS kein IGMP (was für Multicast dringend notwendig wäre) und die Fritzbox dann, was IP-TV für den grössten Kundenkreis (T-Home) funktioniert.
Alles davon ist falsch..
Da kommt murks bei raus..

Makki

[Klaus Gütter]

Hallo Makki,

Das Haupt-Problem in "kleinen" Umgebungen ist aber ein anderes: die SS am HS (USB, FT1.2) können schlicht kein (i)ACK schicken, damit hat man durch 3x Wiederholung die 3x Buslast.

ich weiß ja nicht, in welcher Betriebsart der HS die Schnittstelle betreibt, aber normalerweise lässt man die LinkLayer auf der Schnittstelle laufen und die generiert dann sehr wohl ein IACK. Das gilt auch für eine Schnittstelle, die über Tunneling angebunden ist.

gaert hat mit ACK wahrscheinlich das Tunneling_ack gemeint, nicht das KNX-TP1-IACK. Das sichert (im Gegensatz zu blindem Routing) wenigstens die IP-Netzwerkseite der Kommunikation.

Gruß, Klaus

[makki]

Hallo Klaus,

USB: m.W. geht -auch bei den neueren cEMI-USB nur das (i)Ack für GA's, die in der auf 256 limitierten Addresstable stehen bzw. vorher dort reingeschrieben wurden - und die AddrTable wirkt dann gleichzeitig als Filter; ergo keine Betriebsart, die für HS (mit meistens "etwas" mehr als 256 GAs) in Frage kommt.
Deshalb schreibt man "0" in die AddrTable, was zur Zustelllung aller Telegramme führt, ein ACKen jedoch unmöglich macht.

Tunneling-Ack: das ist natürlich richtig, der Tunneling-ACK/UDP ist im 100Mbit LAN aber doch auch nur Kosmetik fürs Auge Wie soll denn da ein UDP-packerl verloren gehen..

Um das nun allgemein abzurunden, was ich meine (wenn auch bereits 100x geschrieben):
Man benötigt in einer solchen (normalen, kleinen) Installation, zwingend einen Linienkoppler (TP1 oder IP/R), der "blind" die Telegramme auf dem TP1 ACKed, weil man sonst Telegrammwiederholungen bei GA's die nur von/an HS gehen hat und das ist sehr sehr lästig und vor allem für Einsteiger erstmal völlig unverständlich - deswegen, um langsam zum Thema zurückzukommen bin und bleibe ich der Meinung das der vom TE eingesetzte IPR schon genau das richtige ist und die USB-SS nicht.
Denn durch die limitierten Funktionen "nach oben" taugt sie nichtmal zum Debuggen richtig.

Grüsse Makki

[Klaus Gütter]

Hallo Makki,

schau mal in 3/5/1 Abschnitt 4.10.2.3.1. Da steht ganz eindeutig, dass bei Length=0 alle empfangenen Gruppentelegramme geACKt werden müssen. Alles andere wäre auch inkonsequent.

Tunneling-ACK: das hilft schon mal, den eines Ausfalls des IP-Routers oder des Kommunikationswegs dorthin überhaupt zu bemerken. Oder den Ausfall der daran hängenden TP-Linie.

Gruß, Klaus