Closed LinusNil closed 4 months ago
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?
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.
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.
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?
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).
This sounds great. Do you know it this will also be implemented in the iOS version?
I believe keepalives work fine in iOS.
Marking issue with request for more data as stale, due to no updates.
Hi It happens repeatedly that the endpoint queue is growing, even though the "Endpoint state" says "Connected" and I have a really good Internet connection. This is not resolved by restarting the application. The only way I can get it working again is activating/deactivating a Wireguard VPN tunnel I am using. I guess the only reason this works is because it triggers/forces some action in Owntracks making it reconnect to the HiveMQ broker.
I do love the app and I am planning on using it for a very good purpose, so I am eager to find a solution to this issue.
Log