MQTT Exception delivering message (32000) about android HOT 8 OPEN

32000 is the MQTT client exception for REASON_CODE_CLIENT_TIMEOUT. The client's not getting a response back from the server. The fact that this is fixed by restarting your wireguard VPN (which I assume is what you're connecting over) hints that your network is dropping the return packets somehow.

Can you test without Wireguard to see if it still behaves the same?

from android.

I should have been clearer about the vpn. As mentioned the connection issue is resolved by first activating and the deactivating the vpn. In other words; I usually don't use it and even if it is activate, I only route a few LAN subnets through it.

I believe the only thing this does is trigger/force owntracks to reconnect to the broker in some way. I might have come around this issue by using Clean Session, which I believe makes Owntracks open and close the TCP connection repeatedly in some way.

Addition:
I still occasionally run into this issue, also with Clean Session activated.
I also noticed that if I close the app gracefully (with the Exit App menu option) and then start it, it regains connection to the broker and starts working properly.

from android.

Network changes do trigger a reconnect, so that's probably why you're seeing a reconnect.

It does smell an awful lot like a middle router (or something) between your device and your broker is stopping packets from flowing at some point after the connection is established. I've seen this before on some ... interesting NAT implementations & firewalls that had a slightly wonky view on what "connected" meant (they only let traffic flow when there was a connection formed by a TCP handshake, and then at some point forgot that happened so dropped further packets in the flow).

Clean session is just a flag sent to the broker on connect to say "don't send me any outstanding Qos 1 or 2 messages that you might have queued from my last session". It doesn't affect reconnects.

There's a 2.5.0 beta out shortly, I'd be interested in whether or not you experience the same thing there.

from android.

Ok. I got the Clean Session thing wrong then. Thank you for enlightening me on that.

Well, I am behind CGNAT while I'm not on WiFi. Also, my mobile connect to WiFi whenever it is available. Looking forward for updates.

This might be considered a not so desirable workaround, but would it be possible for OwnTracks to simply reinitiate the TCP connection if it runs into these kind of errors for a certain timespan?

from android.

This might be considered a not so desirable workaround, but would it be possible for OwnTracks to simply reinitiate the TCP connection if it runs into these kind of errors for a certain timespan?

One of the things the new version should enable is setting a keepalive to <900s. In theory (because software), this should mean that if the broker / client doesn't see a ping at least every $keepalive seconds, it'll RST the connection and force a re-connect. It sounds like you'd benefit from having a value closer to around 60s (depending on impact on your battery life).

from android.

This sounds great. Do you know it this will also be implemented in the iOS version?

from android.

I believe keepalives work fine in iOS.

from android.

Marking issue with request for more data as stale, due to no updates.

from android.