You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
xDrip+ Sync traffic (over port 25935) can be blocked on some wifi networks
Discussion thread: #3772 relates to this issue.
Bluejay (the replacement for Google firebase messaging) now used by the xDrip+ Sync Service, operates (by default) over port 25935. On some restricted access (e.g. school) networks, non-standard high ports like this are blocked. When this happens, followers will not obtain any xDrip+ sync data on downstream devices.
I suspect that the reverse is also true (i.e. if a follower attempts to connect to xDrip+ Cloud to receive data from the master, this will also fail). I have not validated this scenario, but it seems likely, and should therefore be considered when implementing a solution.
During this time, the push to Nightscout continues to be successful - at this is operated over 443 (and is not blocked).
Your environment
Version: 2024.11.08, but applies to all versions since the switch from Google Firebase messaging to Bluejay was implemented
G6 with BYOD app, patched to broadcast. xDrip+ configured for 640G/EverSense. xDrip+ pushes to Nightscout and is configured for xDrip+ Sync using "new cloud" option.
Expected behavior
xDrip+ Sync Service should be configured in such a way to ensure that it maximises its chances of working correctly on restricted networks, by using a more-standard port (e.g. 443 for encrypted HTTPS). Or if a connection to 25935 failed, then fall back to an alternative port that is less likely to be blocked. (Some consideration may also need to be given to layer 7 packet inspection, when considering a suitable port to use - in-case such inspection might interfere with the transmission of data).
Actual behavior
On networks where port 25935 is not opened, any followers of a xDrip+ Master, will not receive any data until the Master device connects to a different data service (i.e. at the end of a school day).
Steps to reproduce the behavior:
Block outbound traffic to port 25935
xDrip+ will fail to connect to the bluejay messaging service and log the message: "Connection lost, retrying in " + reconnectTime + " ... " + e);
The text was updated successfully, but these errors were encountered:
Subject of the issue
xDrip+ Sync traffic (over port 25935) can be blocked on some wifi networks
Discussion thread: #3772 relates to this issue.
Bluejay (the replacement for Google firebase messaging) now used by the xDrip+ Sync Service, operates (by default) over port 25935. On some restricted access (e.g. school) networks, non-standard high ports like this are blocked. When this happens, followers will not obtain any xDrip+ sync data on downstream devices.
I suspect that the reverse is also true (i.e. if a follower attempts to connect to xDrip+ Cloud to receive data from the master, this will also fail). I have not validated this scenario, but it seems likely, and should therefore be considered when implementing a solution.
During this time, the push to Nightscout continues to be successful - at this is operated over 443 (and is not blocked).
Your environment
Version: 2024.11.08, but applies to all versions since the switch from Google Firebase messaging to Bluejay was implemented
G6 with BYOD app, patched to broadcast. xDrip+ configured for 640G/EverSense. xDrip+ pushes to Nightscout and is configured for xDrip+ Sync using "new cloud" option.
Expected behavior
xDrip+ Sync Service should be configured in such a way to ensure that it maximises its chances of working correctly on restricted networks, by using a more-standard port (e.g. 443 for encrypted HTTPS). Or if a connection to 25935 failed, then fall back to an alternative port that is less likely to be blocked. (Some consideration may also need to be given to layer 7 packet inspection, when considering a suitable port to use - in-case such inspection might interfere with the transmission of data).
Actual behavior
On networks where port 25935 is not opened, any followers of a xDrip+ Master, will not receive any data until the Master device connects to a different data service (i.e. at the end of a school day).
Steps to reproduce the behavior:
Block outbound traffic to port 25935
xDrip+ will fail to connect to the bluejay messaging service and log the message: "Connection lost, retrying in " + reconnectTime + " ... " + e);
The text was updated successfully, but these errors were encountered: