Ergänzung / Ursache weiter eingegrenzt: Inzwischen konnte ich das Problem auf Netzwerkebene reproduzieren und mit tcpdump auf dem Gateway untersuchen. Die TCU200 erreicht grundsätzlich alle benötigten Dienste: DHCP funktioniert DNS funktioniert NTP funktioniert mgmt.viessmann-platform.io auf TCP/443 ist erreichbar dc1-2-iothub-03.azure-devices.net auf TCP/8883 ist erreichbar Der MQTT/TLS-Verbindungsaufbau zum Azure IoT Hub funktioniert zunächst ebenfalls. Anschließend tritt jedoch ein reproduzierbares Problem auf: Die TCU verwendet bei der TCP-Verbindung MSS 1460 und sendet später TCP-Segmente mit 1460 Byte Nutzdaten. Mein Internetzugang hat jedoch nachweislich eine Path-MTU von 1492 Byte. Ein Test vom Gateway liefert ausdrücklich: Frag needed and DF set (mtu = 1492) Für IPv4/TCP wäre bei MTU 1492 eine MSS von maximal 1452 Byte erforderlich. Im Paketmitschnitt ist zu sehen, dass kleinere MQTT/TLS-Pakete noch korrekt übertragen und bestätigt werden. Sobald die TCU 1460-Byte-Segmente sendet, werden diese nicht mehr bestätigt und mehrfach retransmittiert. Anschließend bricht die Verbindung ab bzw. die TCU baut in kurzen Abständen neue MQTT-Verbindungen zum Azure-IoT-Hub auf. Zum Gegencheck habe ich auf meinem Gateway ausschließlich für die TCU und TCP/8883 testweise MSS-Clamping auf 1452 erzwungen. Ergebnis: Unmittelbar danach bleibt die Anzeige der Vitodens auf Verbindung zum Backend: Verbunden stehen und ViCare funktioniert wieder. Im tcpdump sieht man den Unterschied ebenfalls eindeutig: TCU -> Azure: SYN mit MSS 1460 Azure -> TCU: durch das Gateway angepasster SYN-ACK mit MSS 1452 Anschließend läuft die MQTT-Verbindung stabil. Bemerkenswert ist außerdem, dass die MSS-Clamping-Einstellung meines UniFi-Gateways über die normale GUI trotz Einstellung 1452 zunächst nicht wirksam wurde. Erst eine gezielte TCPMSS-Regel auf TCP/8883 führte tatsächlich dazu, dass die TCU MSS 1452 verwendet und die Backend-Verbindung stabil bleibt. Damit scheint zumindest in meinem Fall die Ursache kein WLAN-, DNS-, DHCP- oder ViCare-Problem zu sein, sondern ein MTU/PMTU/MSS-Problem der TCU200 bzw. deren TCP-Stack bei einem WAN-Pfad mit MTU 1492. Vielleicht kann das Viessmann-Team prüfen, ob es Ende August eine Änderung an Firmware bzw. MQTT/Azure-Anbindung gab und weshalb die TCU ihre Segmentgröße bei einer Path-MTU von 1492 nicht selbst korrekt reduziert. Ein dauerhafter Fix seitens Viessmann wäre wünschenswert, da die aktuell funktionierende MSS-Clamping-Regel auf meinem Gateway lediglich ein Workaround ist.
... Mehr anzeigen
