It should be a Bug Report but I would like it to be considered more serious. That is important topic from privacy point of view. I don’t know why there is tendency to hide DNS settings. What is the reason?
There should be a possibility to choose between Automatic DNS Management or set 2 or 3 user DNS addresses in Advanced settings of WLAN and Mobile Network.
The same or biggest bug is applicable for Alien Dalvik. The latest AD doesn’t utilize /etc/resolv.conf at all. That is a nightmare from privacy point of view.
Please bring back DNS user control, particularly when the Sailfish Conmann started ignoring Nameserver variable.
6 Likes
I can understand your request and motivation. But what you call the latest Alien Dalvik is in fact a completely different thing compared to what is available on older phones. It is much closer to a real Android, which does not even know of /etc/resolv.conf at all. To you this looks like a feature that has been lost during development, but what you want has never been there in the current solution for running Android apps on Sailfish OS. I doubt this can be implemented easily.
1 Like
Is the android layer dependent on conman? Or is there an additional service? I’m curious but I don’t run android so I have no way to know.
I am sorry, I don’t know those details: I only own community ported devices at the moment.
Ah, that makes two of us 
I don’t know much about AlienDalvik and how it works in detail, but regarding native SFOS it’s possible to install dnsmasq and disable connman’s DNS management. dnsmasq is able to read /etc/resolv.conf and so brings back control about DNS.
2 Likes
Frankly speaking, I don’t know if is AD dependent on conman or not. It looks like AD uses DNS addresses taken directly from DHCP. Maybe it is via conman. What I know is that AD does not use /etc/resolv.conf.
1 Like
No it doesn’t, /etc/resolv.conf and it settings are ignored by AD.
1 Like
Thanks for info! Do you know where the original DNS settings (DNS server addresses) of ‘connman’ are stored? I lost them doing my experiments, now entered the DNS addresses of my internet provider into /etc/resonv.conf and device works again. But I would really like to have the original Jolla DNS’es back but can’t find them any more.
Answer in another thread. Simply restart connman or a phone then it will recreate symlink to connman’s resolv.conf.
1 Like
Thank you, found it, points to /run/connman/resolv.conf.
edit: there is no information inside except
# Generated by Connection Manager
nameserver ::1
nameserver 127.0.0.1
so, not very helpful.
Thank you for this information. I didn’t know this.
So at the moment in later SFOS versions it isn’t possible to set Android applications to use the same resolv.conf that native applications use?
I can’t check on any device ATM, but another location would be somewhere under /home/.system/var/....
It’s entirely possible though that it doesn’t persistently store its upstream nameservers at all, keeping them just in memory (at least for DHCP-supplied ones).
One thing i noticed is that the android layer does not even use the dns received by the dhcp server. This means that local names are not resolved by android apps (which has annoyed me when using firefox).
I’m not sure what it uses actually (maybe i should sniff the traffic to find it 
). I hope it’s not some stupid public DNS server…
1 Like
I bet it’s good old 8.8.8.8 (i.e. Google)!
Do you mean .local domains provided by avahi-daemon? Avahi is not supported in Android so far.
It works in Firefox though. I have an octoprint instance (octoprint.local) that Firefox on Android resolved no problem while Firefox on SFOS doesn’t.
No it means that if your local LAN has a DNS server which can resolve host names on that LAN (common feature for consumer routers, which do routing, dhcp, and dns all in one), the phone can not resolve these named hosts on the local lan because the name server is never queried.
Careful, avahi/bonjour/zeroconf/mdns is not dns in the sense we’re talking about here (though technically closely related).
Also, there are other ways of discovering devices on the local LAN, such as UPNP, DLNA, Samba, ping floods, …
1 Like