Bring back DNS and /etc/resolv.conf user control

Feature Requests
#7

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
#8

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
#9

No it doesn’t, /etc/resolv.conf and it settings are ignored by AD.

1 Like
#10

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.

#11

Answer in another thread. Simply restart connman or a phone then it will recreate symlink to connman’s resolv.conf.

1 Like
#12

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.

Browser - not working alongside dnsmask
#13

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?

#14

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).

#15

No. I suppose that this is the reason of that issue.

#16

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 :smiley: ). I hope it’s not some stupid public DNS server…

1 Like
#17

I bet it’s good old 8.8.8.8 (i.e. Google)!

#18

Do you mean .local domains provided by avahi-daemon? Avahi is not supported in Android so far.

#19

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.

The dnsmasq and connman may conflict (patch available)
#20

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.

#21

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
#22

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
#23

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).

#24

@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.

#25

You are claiming it works but according this bug it doesn’t. How is that possible?

#26

No. It doesn’t apply to AD.

1 Like