Network Info required on xDrip+ Sync / xDrip Cloud

[dbames]

My son uses a BYOD version of the Dexcom G6 app (as his medical team use Dexcom Clarity). He also runs xDip+ and get his BG data fed into it via BYOD G6. xDrip+ uploads to a Google cloud-hosted instance of Nightscount. My wife and I both follow him with xDrip on our phones, fed via xDrip Sync.

Before the change to xDrip+ sync (due to the removal of Firebase), this was a bullet proof solution and worked successfully regardless of what network my son's phone was connected to (be it data, home/school/public wifi).

Now the tricky part. We're continuing to use xDrip+ sync based on the alternative messaging system (via the "new xDrip cloud server") and on the whole this works pretty well. Apart from when my son's phone is connected to the school's wifi network. In this scenario, the sync clients don't receive any readings. If I check in Nightscout, data is being successfully pushed there. As a workaround, I know I can configure our xdrip+ followers to retrieve data from nightscout. I think if I turn off "new xDrip+ cloud servers" - xDrip+ will fall back to the now non-functioning Google firebase messaging stack.

This suggests to me that the school's wifi is somehow "breaking" xdrip+ sync functionality. In order for me to discuss with the school and attempt to find a resolution, it would be useful to understand how this model works, what servers/protocols/ports, etc. are in use. I'm hoping that someone might be able to provide some insight.

Update: a quick poke around the code suggests jamcm3749021.bluejay.website:25935 and legacypush188263.bluejay.website:443

[Navid200]

Thanks for such a well-written description. I have already notified our lead developer. If we can help, he will respond here. Thanks.

[dbames]

If my review of the code is correct, my gut suspicion is that the use of such a high-range port is the underlying issue. Whilst your lead developer investigates, I will discuss with the school to see if they're blocking outbound requests to non-standard ports - which would at least confirm the underlying cause.

Going forward, should it be the case, then if xdrip cloud were to operate over a more standard port (e.g. 443), it would less likely be blocked on restricted networks.

[dbames]

Update 14/11/2024: My son's school were receptive to the request and have whitelisted jamcm3749021.bluejay.website:25935 for outbound traffic on their perimeter firewalls. As of this morning, we're now receiving data via xdrip+ sync.

Whilst this clearly isn't a bug, I do wonder if consideration could be given to using a more standard (aka less-likely-to-be-blocked) port for xdrip+ sync traffic. Depending on the protocol and whether (layer 7) traffic inspection is in-place, might well influence port selection.

[tzachi-dar]

There is a workaround that I have created for the issue:
On the file pusher.jave on line 219 you need to connect to:
"jamcm3749021.bugaloop.com", port 443

This is a server that I have built and forwards the traffic.
(Don't worry about privacy, the data is end to end encrypted)

[dbames]

That's an interesting workaround. I had been considering whether I could proxy the traffic through the existing google-cloud vm I have for nightscout. With you having done it, it now save me the bother (and then working out how to actually build/package xDrip!)

Where-ever possible, I like to keep things (code, traffic flows, etc.) as simple as possible. This proxy introduces another link in the chain, which could make troubleshooting trickier in the future.

Perhaps an extra UI option could be added, to offer to route traffic via this proxy on 443 - for networks that block the higher ports.
Or consider running the xDrip+ sync service over 443 by default (and for a transition period have a proxy on 25935 to cater for users who haven't updated) .

Would you like me to raise an enhancement request for it?

[tzachi-dar]

The preferred solution is for the xDrip+ sync service to run over port 443. Please open an enhancement request for it.