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
Isn’t connmand used by default? So don’t change /etc/resolv.conf but connmand’ s nameserver config. First list the services:
# connmanctl services
*AO SSID wifi_xyz_xyz_managed_psk
*A XYZ cellular_IMSI_context123
Next you can change the nameserver:
# connmanctl config wifi_xyz_xyz_managed_psk --nameservers 9.9.9.9
That change should apply to AD as well but will be overwritten by every network change.
1 Like
Exactly. And mdns can be resolved at the application level (i suppose that’s what firefox does when it detect an address ending in .local).
@kan_ibal I fully agree to your initial request, once, as you wrote, because of AD, to keep control over what Android apps may do, but also in general to retain control over wanted or preferred device behavior.
In the last few days I struggled with making dnsmasq work in parallel to connman’s central role in SFOS, and unluckily failed.
wiki.ubuntu says about connman: ‘The Connection Manager is designed to be slim and to use as few resources as possible, so it can be easily integrated.’
Searcing the net and comparing range of functions of both, in my opinion connman is too slim. My idea (and suggestion) is, Jolla should replace connman by dnsmasq, and restore full user control over it.
edit: Or Jolla could provide a well tested way to enable dnsmasq beside connman without crashes and one break the other.
No. It doesn’t apply to AD.
1 Like
You are right. I just ran a trace and tcpdump told me that AD uses 9.9.9.9 with DNS over TLS (port 853) for DNS resolution by default. In this thread they claim, that blocking these requests will make android fall back to plain DNS (port 53) but I haven’t tested that.
Edit:
After
[root@xperia ~]# iptables -A OUTPUT -p tcp --dport 853 -j REJECT`
AD uses 9.9.9.9 on port 53 and still not connmand. But now a redirect to some other DNS server becomes feasible.
2nd edit:
I tested some more. DNS over TLS can be disabled in the Android settings app, no need for a firewall hack.
apkd-launcher com.android.settings.apk com.android.settings/com.android.settings.Settings
There you also find the DNS IP that is in use for your current connection. It seems to be provided by connman since it shows my locally changed address (9.9.9.9 at that time).
My attempt to set a consistent DNS system for SailfishOS as
DNS alternative package that contains set of config files.
Dnsmasq serves as local DNS service @127.0.0.1, Dnscrypt-proxy serves as DNS service for external request @127.0.0.1 with blocklist (ads, malware etc.). AlienDalvik uses /etc/host via dnsmasq.