MQTT communication gets stuck via VPN connections

[syssi]

I've extended the TemperatureSensor example by 5 additional temperature HomieNodes. On boot the node gets stuck at the first publish of the configuration (the size of the message exceeds the MSS of 1336 bytes). My MQTT broker is located on another location accessible by OpenVPN. If I deploy a local MQTT broker the problem disappears (MSS 1460). If I reduce the length of the base topic, device id and property names the problem disappears also. I've attached screenshots of two tcpdumps. The long one is a proper connection to a local broker. The another one shows the node stuck after the MQTT "connect ack".

After some time (keep alive timeout) the Node drops the MQTT connection and does a reconnect. The drop of the connection can be delayed by

Homie.getMqttClient().setKeepAlive(30);
Homie.setup();

A higher timeout does not solve the issue. The mosquitto.log shows the dropped connection as:

1495974899: New client connected from 192.168.130.53 as Homie-kitchen (c1, k15, u'username').
1495974920: Client Homie-kitchen has exceeded timeout, disconnecting.

[syssi]

@me-no-dev do you have an idea whats happening here? It's a MSS problem and could it be ESPAsyncTCP related?

[marvinroger]

Yes, the problem is in the underlying TCP lib. I cannot help here. 😕

[me-no-dev]

AFAIK we have done everything possible to help with this. AsyncTCP reports everything that gets to it.

[marvinroger]

Maybe the esp8266/Arduino 2.4.0 will help? I saw there's a WIP to port pure lwip 2.0, too.

[syssi]

I will give it a try!

[marvinroger]

Please also try with the latest AsyncMqttClient, it solved the timeout issue.

[syssi]

I've updated a few libraries/components:

Arduino/libraries/homie-esp8266: master 65c7944cc21e5d48834565b19b4a0dd1b8581166 Arduino/libraries/async-mqtt-client: master 04a8332d965e083a572626cffeffd7308d5b7719 Arduino/libraries/ESPAsyncTCP: master 3d030db489e263e16a5af43a095c83c12ed8e451 Arduino/hardware/esp8266com/esp8266: master db8868da1d70517a28feefc1310b423d5710cba8

Unfortunately it does not fix the issue.

[Gulaschcowboy]

Hi everybody, please excuse me for jumping in here. I have the same problem with remote nodes behind ADSL lines here in Germany. Their MTU is 1492 bytes and sometimes even lower (seems to have some L2TP in between. The initial package that contains ../$implementation doesn't get transferred over such line as the underlying packet is seems to be too big: seq 104:1564, ack 5, win 5836, length 1460 This is reproducible, as I have a test bed where I can direct the packet over lines with MTU of 1500 which works and with lower MTUs it doesn't work

Following this thread I tested with esp-arduino 2.4.0-rc1, still same problem. :-( As I'm not deep enough at all into the underlying libraries: Isn't there a way to manually patch the crafted packet size e.g. in ESPAsyncTCP @me-no-dev ? Or is this a problem which can only be solved within esp8266/Arduino? If yes, can somebody support me to file a bug to @iggr?

Thanks.

[stritti]

Closing this issue because of no progress for long time.

[allComputableThings]

Is this still an outstanding bug? I see it was closed but no sign it was fixed. (I'm having issues with keeping an connection over vpn).