Tool zur Simulation eines Multicast-Backbones gegenüber der ETS?

[sb4820]

Hallo zusammen,

für Test- und Diagnosezwecke (u.a. Weiterentwicklung meiner KNXnet/IP-Funktionsblöcke für Beckhoff) würde ich gerne die Möglichkeit haben, von der ETS aus via Multicast GroupWrites zu generieren und zu empfangen, ohne immer zwingend einen KNXnet/IP Router mit dranhängen zu haben, der schön brav der ETS ihre SearchReq-Pakete mit SearchResp beantwortet, damit ich einen entsprechenden Backbone in der Schnittstellenliste angezeigt bekomme.

Wollte heute schon selbst was schreiben, dann kam aber die Ernüchterung: Es reicht nicht, die SearchResp einfach an den Port 3671 zu senden, sondern die ETS macht natürlich prompt für jeden SearchRequest einen neuen Port auf und will den mutmaßlich auch dahin wieder beantwortet haben. Sonst hätte ich einfach zyklisch SearchResponses rausgeballert und gut ist. Aber so einfach ist es dann natürlich nicht. GRMPF.

Vor ich da jetzt weiterbastel: Gibt es das was ich suche vielleicht schon fertig? Habe auf die Schnelle nichts gefunden, aber eventuell geht mir ja einfach nur das passende Stichwort ab...

So oder so müsste man das Tool wahrscheinlich dann schließen, vor man den Gruppenmonitor anschmeißt, da es ja selbst auf Port 3671 hören muss (um die SearchReqs der ETS zu empfangen). Den soll ja aber die ETS dann später wieder öffnen können, um auf den Backbone zuzugreifen. Das sollte aber in der Theorie funktionieren - wenn ich die Schnittstelle mal angewählt habe und dann zum Gruppenmonitor wechsle, sind glaube ich keine Abfragen mehr erforderlich, wenn ich das noch richtig in Erinnerung habe, nicht mal beim Start der Diagnose.


Gruß Stephan

[meti]

https://github.com/calimero-project/calimero-server

Die SearchRequests, sowie RoutingIndications werden alle an eine Multicastgruppe gesendet - da brauchst du eigentlich nix zu schließen.

[sb4820]

Schau ich mir gleich mal an.

Wahrscheinlich hab ich mich mit dem Schließen unglücklich ausgedrückt. Ich muss die SearchResponse ja an den lokalen Port schicken, von dem der SearchRequest ausging. Der Request geht per Multicast an den Port 3671, das heißt mein potentiell zu entwickelndes Tool muss auf diesem Port lauschen, um eben diesen Quellport der ETS herauszufinden. Das würde aber später beim Starten der Diagnose mit der ETS kollidieren, wenn diese selbst ein Socket auf der 3671 öffnen wollen würde, was unter Windows nicht möglich ist (Zugriff auf den selben Port durch zwei Programme). Sonst müsste das Tool auf nem anderen Rechner laufen als die ETS, das möchte ich eigentlich vermeiden.

[meti]

Ich kann mir irgendwie nicht vorstellen, dass mehrere Applikationen nicht den selben Multicast Port benutzen können (TCP von mir aus, UDP und Multicast im speziellen aber nicht). Aber hab auch keine Ahnung von Windows 🤷

Ich muss die SearchResponse ja an den lokalen Port schicken, von dem der SearchRequest ausging.

Die Response sollte an die HPAI geschickt werden die in der Request als Discovery Endpoint mitgesendet wird. Ich glaube aber, dass ein Response an die Multicast Gruppe genau so zulässig ist.