There is nothing to elaborate further. --nodnsproxy has nothing to do with /etc/resolv.conf
Use your config in SFOS and observe /etc/resolv.conf after Connman restart. Change at first /etc/resolv.conf to non standard:
rm -f /etc/resolv.conf
touch /etc/resolv.conf
echo ‘1.1.1.1’ > /etc/resolv.conf
1 Like
I tested that and looked into the sourcecode of connman, you’re right.
The manpage states
-r, --nodnsproxy
Do not act as a DNS proxy or support external DNS resolving. Depending on how ConnMan is compiled, it will by default direct all DNS traffic to itself by setting nameserver to
127.0.0.1 in resolv.conf(5) file or leave DNS management to an external entity, such as systemd-resolved. If this is not desired and you want that all programs call directly some DNS
server, then you can use the --nodnsproxy option. If this option is used, then ConnMan is not able to cache the DNS queries because the DNS traffic is not going through ConnMan and
that can cause some extra network traffic.
Which is misunderstandable. Somehow this never has been a problem when I used this on my laptop, probably because resolved just overwrote the file. Thx for this correction. I’ll submit a correction to the manpage upstream.
Edit: Removed wrong statement.
Not exactly because /etc/resolv.conf created by Connman is a symlink to /var/run/connman/resolv.conf. I needed /etc/resolv.conf as text config file to write in it.
The manpage for Connman has nothing in common with reality of Jolla’s Connman in SFOS.
There is a chance to solve this /etc/resolv.conf mess, but question is what about with Connam’s upgrade in SFOS to current version? The current is 1.41 but SFOS uses heavily patched 1.32 from 7 years ago.
1 Like
The fallback code is the same on upstream and Jolla’s fork, I compared them.
Interestingly, /var/run/connman exists on my Laptop without RuntimeDirectory=connman set. This should explain then why I never came accross the behaviour when I used the --nodnsproxy option.
It exist because it is a file that connman creates and will be. RuntimeDirectory parameter should prevent connman from removing /etc/resolv.conf file and from creating a symlink instead. The goal is to keep connman away from /etc/resolv.conf.
I have tried this approach
[root@sfos defaultuser]# systemctl edit connman
[Service]
Nameservers = 127.0.0.1
[root@sfos defaultuser]# systemctl daemon-reload
[root@sfos defaultuser]# systemctl restart connman
[root@sfos defaultuser]# cat /run/connman/resolv.conf
<DNS from network operator and VPN provider>
My expectation was see nameserver 127.0.0.1 in /run/connman/resolv.conf but it does not happen. Something was wrong but syntax is correct, possibly it is not the right file/section:
Unfortunately, I have quite no experience with connman and I searching for suggestions and/or inspiration.
UPDATE
I found the place:
/home/.system/var/lib/connman/cellular_xxxx_context1/settings
the section is related to the SIM id:
[cellular_xxxx_context1]
Nameservers=127.0.0.1;
Moreover, any other option that I tried to put in this section will be removed when the mobile data connection changes state but not the Nameserves line which receive a demicolon at the end. Thus, it is persistent and it is a field that can be fulfill (optional) in
Settings:System → Connectivity:Mobile network
Unfortunately, the UI does not allow to set that field.
Your first approach was to set it in the systemd service file. - As long as there isn’t any environment var or flag defined there, there aren’t settings of the program itself in there. This file is for the startup and lifetime of the executed program.
In the second thing you set the DNS for a specific connection, but not globally, so everytime you use a different connection, it won’t apply your setting. Every Wifi is a different connection and I doubt you want to set it everytime.
The other way to set this is way smarter.
Since this discussion the connman manpage got updated so that it’s more clear that --nodnsproxy still manipulates the resolv.conf.
2 Likes
First of thanks @oroesler for the reply.
Yes, it is but in /run/connman/resolv.conf and /etc/resolv.conf is just a link. Removed that link the connman manipulations can be useful or ignored. I have explained in more specific details in here:
Since, the start of my posting I have updated my patch 3 times. By now, I think that I reached a conclusion about dnsmasq integration with connman.
I have not extensively tested this patch yet because I am using the smartphone for experiments, developing and my personal use. Quite an extreme but coherent decision. Therefore, I need the right slot of time to pkcon refresh the packages at their default configuration, check it and then apply and test extensively the patch to be sure that everything I did by hands has been correctly reported into the patch.
It is already discussed at forum:
but as @oroesler already mentioned that way is not convenient to use.
Regarding patch, the proper way to alter system services is using “override.conf”.
If you had a time to read you would spot that most of your concerns are already explained and solved at DNS alternative.
2 Likes
It is an obsolete way of doing because as far as I see, what was doing that stuff has been adopted for default in the current installation of connman which mangle /run/var/etc/resolv.conf not anymore /etc/resolv.conf which is a mere link.
Yes, I see that it is a promising way to go and problably the definitive answer about DNS proper dealing in SFOS. Unfortunately, the Spectrum 16kb kid which is in me, decided to fix the dnsmasq package becase there are two ways: 1. fix it XOR 2. remove it. Make no sense to keep a package that conflicts with connman and in the best failre degrade the system status.
Moreover, I wish to get into the system and see by my own eye its architecture and doing it with dnsmasq was a viable solution that also let me understand the solving-problem typical process of this community. A 2nd insight because the A-GPS case might have been a lucky one.