i3-Technologies server addresses and ports

\uD83E\uDD14 Problem

Server information for troubleshooting license, connection and/or updating problems.

\uD83C\uDF31 Solution

Preferred method for all whitelisting the i3-technologies.com and i3-connect.com servers is to ask the customer to whitelist *.i3-technologies.com, *i3-technologies.services, *i3-connect.com and *i3-connect.services. This is easiest, and you don’t have to do anything if we ever do a minor change to a server address. If this is not possible (or allowed), then these are the server addresses in use at this time:

General domains:

• i3-technologies.com

• i3-technologies.services

• i3-connect.com

• i3-connect.services

License Server:

• https://license.i3-technologies.com

I3Allsync License Server

• https://i3allsync.license.i3-technologies.com

Firmware Server

• https://ota.i3-technologies.com

• https://ota.i3-technologies.services

• https://ota.i3-connect.com

• https://ota.i3-connect.services

Software Update Server:

• https://updates.i3sw.i3-technologies.com

• https://software-updates.i3-technologies.services/

• https://updates.i3sw.i3-connectc.com

• https://software-updates.i3-connect.services/

i3RDM server

• https://rdm.i3-technologies.com

• https://rdm.i3-technologies.services

• https://rdm-socket.i3-technologies.services

• https://rdm.i3-connect.com

• https://rdm.i3-connect.services

• https://rdm-socket.i3-connect.services

• https://video.twilio.com

• https://global.vss.twilio.com/

• http://userprofiles.i3-technologies.services

• https://cortex.i3-connect.com

AWS S3 Locations:
(The endpoints below contain wildcards)

• https://i3ota[*].s3.eu-west-1.amazonaws.com

• https://i3store[*].s3.eu-west-1.amazonaws.com

• https://i3-qr-service[*].s3.eu-west-1.amazonaws.com

• https://i3-rdm[*].s3.eu-west-1.amazonaws.com

Firewall ports that need to be open: 80 and 443

Android uses a built-in mechanism for captive portal detection and connectivity validation rather than a full “ping” to a server.

Here’s how it typically works:

• HTTP Request to a Known Endpoint:

The system sends a lightweight HTTP GET request to a predetermined URL (commonly something like http://connectivitycheck.gstatic.com/generate_204 or http://clients3.google.com/generate_204). This endpoint is chosen because it’s expected to return a specific response code (HTTP 204 No Content) when there’s unobstructed internet access.

• Response Verification:

If the request returns a 204 response, Android assumes that the network is validated and has internet access. If the response is different—such as a redirect or an HTTP 200 with content—it may indicate the presence of a captive portal (a login page or some other form of interception) or that the connection is somehow limited.

• Additional Checks:

While the primary mechanism is the HTTP check, Android may also perform DNS resolution checks or combine multiple signals to determine connectivity. These checks are handled in the background by system services like ConnectivityService and NetworkMonitor.

In summary, Android’s background checks rely on these HTTP requests and response validations (along with additional network tests) to assess whether a connection is truly internet-capable.