Ich bin an dem Problem noch ein wenig verzweifelt, aber ich konnte es dennoch lösen. Ich habe auf mein TUNNELLING_REQUEST deshalb keine Antwort bekommen, weil das Gateway zwischen „Rahmen“-Anfragen und „Daten“-Anfragen unterscheidet. Die Rahmenanfragen muss man mit einem anderen lokalen Port versenden, als später die eigentliche Dataanfrage, hier das TUNNELLING_REQUEST.
Diese beiden unterschiedlichen, wenn auch beliebigen Ports, muss man schon in der ersten Anfrage (CONNECTION_REQUEST) korrekt mitteilen. Um Portüberschneidungen auf dem Client zu vermeiden, sollte man die lokalen Ports durch das Betriebssystem vergeben lassen.
So sieht nun eine saubere KNXnet/IP cEMI Anfrage (schreibend) aus. Hier ist es das Einschalten einer Lampe auf der Gruppenadresse 1/0/2
1st: sending CONNECT_REQUEST
06 10 02 05 00 1a 08 01 c0 a8 0a b3 d9 6d 08 01 c0 a8 0a b3 d8 36 04 04 02 00
2nd: receiving CONNECT_RESPONCE with no errors
06 10 02 06 00 14 49 00 08 01 c0 a8 0a 0e 0e 57 04 04 10 01
3rd: sending CONNECTIONSTATE_REQUEST
06 10 02 07 00 10 49 00 08 01 c0 a8 0a b3 d9 6d
4th: receiving CONNECTIONSTATE_RESPONCE with not errors
06 10 02 08 00 08 49 00
5th: sending TUNNELLING_REQUEST (Switch the lighbumb on, at 1/0/2)
06 10 04 20 00 15 04 49 00 00 11 00 bc e0 00 00 08 02 01 00 81
6th: receiving TUNNELLUNG_ACK with not errors
06 10 04 21 00 0a 04 49 00 00
7th: receiving TUNNELLING_REQUEST from gateway to proof our request (change bytes from 11 to 2e)
06 10 04 20 00 15 04 49 00 00 2e 00 bd e0 10 01 08 02 01 00 81
8th: sending TUNNELLING_ACK
06 10 04 21 00 0a 04 49 01 00
9th: sending DISCONNECT_REQUEST
06 10 02 09 00 10 49 00 08 01 c0 a8 0a b3 d9 6d
10th: receiving DISCONNECT_RESPONCE without errors
06 10 02 0a 00 08 49 00
Jetzt kann ich das Ganze modifizieren und die aktuellen Leistungsdaten ins KNX Netz senden.
So sieht das dann in Wireshark mit KNXnet/IP Plugin aus:
Wer genau wissen will, was welches Byte bedeutet und wie man das selbst umsetzt, der guckt sich das am besten hier an.