<< Kommunikation mit Buderus Gateway KM100 (Teil 1) | Home | Kontakt

Kommunikation mit Buderus Gateway KM100 (Teil 2)

ECN - bitte nicht!

Im Teil 1 zu meinen Erkenntnissen über Buderus KM100 beschrieb ich, daß das KM100 mehrfache parallele Verbindungen nicht mag. Ich hatte dann den Java-Client so weit entwickelt, daß er stabil lief und nun sollte er auf meiner FreeBSD-Maschine laufen. Hier erhielt ich überraschenderweise Timeout-Fehler beim Kommunikationsaufbau. Ich hatte für das Socket.connect() einen Timeout-Wert von 3s angegegen, das sollte doch eigentlich reichen. Also hieß es für mich mal wieder das geliebte tcpdump anzuwerfen. Was sah ich da auf Anhieb? Der Verbindungsaufbau wurde sofort mit RST abgelehnt. Das initiale SYN sah aber etwas anders als zunächst erwartet aus, ich sah Flags [SEW], also außer dem erwarteten SYN-Flag waren noch gesetzt W (ECN CWR) und E (ECN-Echo).

Und da erinnerte ich mich sofort: schon vor längerer Zeit hatte ich Explicit Congestion Notification (ECN) nach RFC3168 eingeschaltet und bisher keine Probleme dabei gesehen. Jetzt dämmerte mir auch, warum bei meinen ersten Versuchen mit der Kommandozeile und curl und openssl der Abruf immer so zäh war. Das FreeBSD stellte schon fest, daß die Gegenstelle nicht auf ECN steht und baute die Verbindung ohne ECN auf, aber da waren dann schon einige Sekunden vergangen.

Da für jede Abfrage an das KM100 eine neue HTTP-Verbindung aufgebaut werden muß, konnte ich mich also nicht darauf verlassen, daß das FreeBSD automatisch erkennt, daß ECN nicht möglich ist. Jeder Serviceabruf würde mehrere Sekunden dauern. Also schaltete ich den aktiven ECN-Verbindungsaufbau auf meinem FreeBSD-Server wieder aus (sysctl net.inet.tcp.ecn.enable=2) und die Kommunikation mit dem KM100 funktionierte auch unter FreeBSD schnell und problemlos.

Lektion 2:
Obwohl der Standard zu ECN schon 2001 veröffentlich wurde, hat es Buderus bis heute auf dem KM100 nicht geschafft, das TCP-Protokoll kompatibel zu implementieren. Dazu müßten nur die ECN-Bits ignoriert werden, dann würde alles perfekt laufen. Durch den Verbindunngsabbruch ist man aber gezwungen, auf dem die Verbindung initiierenden Client ECN explizit abzuschalten.



Kommentar hinzufügen Trackback senden