SUPL connections, time server and strange behaviour in DNSNet

harp

Not sure if this fits better here or in third party apps section, because it's related to both.

First some general questions:

If every location service settings in GOS are disabled or turned of except SUPL and PSDS are set to grapheneos.org servers, will SUPL (and PSDS) still be used (and for what purpose)?
The automatic time setting in GOS uses still time.grapheneos.org and doesn't connect to anything else, right?

That leads me to some strange behavior or connections when using DNSNet Blocker. After start blocking the blocking protocol/log shows immediately 1 connection to supl.grapheneos.org and 2 connections to each of 4 different .pool.ntp.org adresses (with leading digits 0 to 3). If you turn of blocking and turn on again, the number of connections rises, 1 more to supl, 2 to each ntp. When you clean the log while blocking is still active (turning logging off and on) then also connections seem to be triggered, but now 2 for supl and 2 for the ntp.org-adresses.

The ntp.org connections seemingly only appear when using WiFi. When you turn off WiFi and mobile data on, only the behavior of connections to SUPL can be observed. More strange: Even after going back to WiFi there will be no more connections to ntp.org. But it you log in to a secondary profile - by the way the described behavior can only be observed in owner profile, not in a 2nd (or it's not shown in the log of the app there) - after going back to owner profile the ntp-connections appear again.

The first time I recognized this I thought these connections were independent form that app and were related to GOS in any way. That's why I ask my initial general questions. I wondered especially about the ntp.org connections because I knew GOS is using it's own time server. But after some trial I figured out the described behavior. I also tried some with system time settings to provoke a time server connection, but although time was synchronized in DNSNet didn't appear a connection, not to GOS serve nor another to ntp.org.

So I'm asking here first, maybe someone has ideas or explanations for that. The other option would be opening an issue at the developers GitHub site but that seems to be more likely a question of understanding than what is the issue is tracker primarily for.

GrapheneOS

harp

If every location service settings in GOS are disabled or turned of except SUPL and PSDS are set to grapheneos.org servers, will SUPL (and PSDS) still be used (and for what purpose)?

The Location toggle controls whether apps can use location. The OS can still use it such as to obtain location occasionally to prepare for the user making emergency calls via Wi-Fi calling. It sounds like that's what you're describing below, particularly the OS making sure that if you make an emergency call via Wi-Fi calling it will be able to provide a location.

The automatic time setting in GOS uses still time.grapheneos.org and doesn't connect to anything else, right?

Yes, but Samsung gnssd introduced another NTP connection we need to deal with by changing it to time.grapheneos.org as we did with Qualcomm previously. It's not intended.

harp

GrapheneOS Thanks for the reply.

GrapheneOS The OS can still use it such as to obtain location occasionally to prepare for the user making emergency calls via Wi-Fi calling.

I'd already suspected that cause I read about that in the past and it also can be read in the location settings section too. I just asked myself if there could be other purposes beyond that. WiFi-/Bluetooth-Search and Network Location are disabled too, so these should be excluded.

GrapheneOS It sounds like that's what you're describing below, particularly the OS making sure that if you make an emergency call via Wi-Fi calling it will be able to provide a location.

Do you mean the observed connections in the DNSNet app. No, I'm convinced, these are definitely triggered by the App. There are connections only logged (and counted) when they are actually triggered. As I described, they count, when tab the start button for the blocking function within the app. I can't imagine that the system checks the the ability of providing location for emergency calls by chance exactly when you tap this button. And surely not e.g. 20 times in 10 seconds (when you tap the button 20 times in 10 seconds). Same with the ntp.org connections, they are triggered together with supl exactly when tapping the start button or toggling on logging. (Or maybe toggling off logging, can't confirm that exactly while it can only be seen after logging turned o again.)

Ok, there's still the chance that it's a bug within the app showing these mistakenly. But any other connections seem to be shown correctly. The only exception I could realize is time.grapheneos.org, which won't be logged there even when time synchronization really happens (and also no other connection instead). So I still wonder why these connections are triggered by the app.

GrapheneOS Yes, but Samsung gnssd introduced another NTP connection we need to deal with by changing it to time.grapheneos.org as we did with Qualcomm previously.

That is already changed to time.grapheneos.org? Or if not, it's not using pool.ntp.org?