You are not logged in.
Hello:
Rather embarrassed, I am at a loss to explain or understand what is going on, so I'd appreciate some input on this.
As per this thread regarding whatever goes on these days with /etc/resolv.conf and how to solve the DNS issues involved, I understood that my box running a default Devuan Daedalus/XFCE installation ran with network-manager installed.
I had no doubts with respect to that being so because /etc/resolv.conf clearly read:
~$ cat /etc/resolv.conf
# Generated by NetworkManager <- # this
# search home
--- snip ---
~$
Not only that, the file was being constantly rewritten with the # Generated by NetworkManager banner at the top.
The file's timestamps was sufficient proof, so what to think?
There are also NetworkManager files all over the system:
/$ locate NetworkManager
/etc/NetworkManager
/etc/NetworkManager/NetworkManager.conf
/etc/NetworkManager/dispatcher.d
/etc/NetworkManager/dispatcher.d/ntpsec-ntpdate
--- snip ---
/usr/lib/NetworkManager
/usr/lib/NetworkManager/conf.d
/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf
/$
Not so fast ...
This morning, while doing further research on the matter I found a thread that led me to have a look at /etc/init.d, coming across this surprise:
~$ ls /etc/init.d | grep network-manager
~$
Ooops ...
A further manual inspection showed me this:
~$ ls -1 /etc/init.d -v
README
--- snip ---
connman~
connman
--- snip ---
networking
nfs-common
--- snip ---
~$
ie: there is a connman entry but there is no network-manager entry
So I asked apt:
~$ apt list | grep installed | grep network-manager
--- snip ---
~$
~$ apt list | grep installed | grep connman-
--- snip ---
connman-gtk/stable,now 1.1.1+git20180626.b72c6ab-3 amd64 [installed]
connman-ui/stable,now 0~20150623-1+b2 amd64 [installed]
~$
What is going on?
Could it be possible that connman does not over write the whole /etc/resolv.conf file and just edits the DNS addresses?
And where did the # Generated by NetworkManager banner come from?
I do not/can not recall using anything but WiCD from Jesse or ascii onwards.
This is a Beowulf -> Chimaera -> Daedalus upgrade which had quite a few issues, all finally solved.
Beowulf ran with the last available WiCD, no idea what Chimaera upgraded to as the desktop and most XFCE settings were mangled up during the upgrade making it unusable so I decided to continue on to Daedalus.
Only then was I able to finish settings things up properly.
For the moment the fix posted by fsmithred seems to have worked. (via chattr)
ie: survived this morning's boot but I'll have to wait and see what happens if/when my fibre provider decides to do one of their remote router resets.
In any case, from what I have read on-line, both connman and network-manager have a go at /etc/resolv.conf, so it will be back to WiCD when it finally gets to the Debian/Devuan repositories.
Any comments welcomed.
Thanks in advance,
A.
Last edited by Altoid (2024-09-17 12:37:14)
Offline
Given that your /etc/resolv.conf is a link it suggests you also have the package resolvconf installed, and that would provide an additional depth to the confusion.
But in any case, DNS setting is part of the DHCP protocol; you know, when your machine contacts the router so as to get an IP address. At that time your machine is also told the IP address of the outbound gateway and the address of the DNS server(s). Those are suggestions by the DHCP server (your router) which get digested by the DHCP client running on your machine. The IP address is assigned to the network interface (via a kernel system call); the gateway IP is assigned to the routing table (via another kernel system call), and the DNS IP address(es) is registered in the file /etc/resolv.conf.
All that happens regardless of which networking software you use; whether it's plain ifupdown, wicd, network-manager or connman.. or whatever.
With resolvconf, you (unbeknowingly?) have opted for a local control of /etc/resolv.conf which is at odds with most networking software unless it also is configured to avoid messing with /etc/resolv.conf. Your first step towards bliss would be to purge resolvconf and reinstate /etc/resolv.conf as a text file.
Offline
Hello:
... /etc/resolv.conf is a link ...
Yes.
mc sees it as @resolv.conf.
... suggests you also have the package resolvconf ...
Checked but no, it is not in my system:
~$ apt list | grep installed | grep resolvconf
--- snip ---
~$
~$ apt list | grep resolvconf
--- snip ---
resolvconf-admin/stable 0.3-1 amd64 # not installed
resolvconf-admin/stable 0.3-1 i386 # not installed
resolvconf/stable,stable 1.91+nmu1 all # not installed
~$
Would that be a bit less confusion?
... happens regardless of which networking software you use; whether it's plain ifupdown, wicd, network-manager or connman.. or whatever.
I see.
The thing is that (for the time being) everything works as per my needs with the chattr fix for /etc/resolv.conf.
The mystery regarding the how/why of the presence of NetworkManager files in my system remains.
ie: I seriously doubt I had anything to do with that, this system has (at least) been upgraded from ascii or maybe even Jesse.
But I recall always having used WiCD.
Maybe the default in Jesse or ascii was NetworkManager and was not properly/totally purged? Would not be surprised.
But it is too long ago for me to remember the details.
Q1: what to do with all these?
/etc/NetworkManager
/etc/NetworkManager/NetworkManager.conf
/etc/NetworkManager/dispatcher.d
/etc/NetworkManager/dispatcher.d/ntpsec-ntpdate
/usr/lib/NetworkManager
/usr/lib/NetworkManager/conf.d
/usr/lib/NetworkManager/conf.d/no-mac-addr-chan
ge.conf
... purge resolvconf and reinstate /etc/resolv.conf as a text file.
Makes sense ...
But /etc/resolve.conf links to /run/connman/resolv.conf which is a file produced by connman, not NetworkManager or resolveconf which is not installed in my system:
~$ readlink -f /etc/resolv.conf
/run/connman/resolv.conf
~$
Q2: would that not break something?
The more I go down this hole, the more (and more) I agree with that chap from stackexchange. 8^°
I have now edited /etc/resolv.conf.
From this:
~$ cat /etc/resolv.conf
# Generated by Connection Manager
search Home
nameserver 192.168.1.11
~$
To this:
~$cat /etc/resolv.conf
# edited by user 17092024
nameserver 192.168.1.11
~$
And we'll see how that goes.
Thank you very much for your input.
Best,
A.
Offline
Hello:
And we'll see how that goes.
Badly or not-as-expected.
My conky setup queries my DNS and I can see it on-screen.
One moment it was as-expected and the next time I looked it had changed.
As posted previously, I has left it at this ...
~$cat /etc/resolv.conf
# edited by user 17092024
nameserver 192.168.1.11
~$
... and now it is this:
~$ cat /etc/resolv.conf
domain Home
search Home
nameserver [my fibre provider DNS]
nameserver [my fibre provider DNS]
~$
Maybe I did not do the chattr -f +i /etc/resolv.conf routine correctly?
Cannot say as I am unable to check the file's attrbutes:
~$ lsattr /etc/resolv.conf
lsattr: Operation not supported While reading flags on /etc/resolv.conf
~$
Hmm ...
I finally found what the -f modifier does.
It happens that it does not mean force, it just suppresses error messages.
I will edit the file again, boot into recovery/repair mode and try to set it from there.
What a load of crock ... 8^/
I will report back once I am done.
Best,
A.
Offline
Hello:
... will report back ...
No dice.
I have found no way to apply chattr to resolv.conf.
Tried with repair mode and booting a Knoppix.
Probably because it is a symlink. (?)
The strange thing is that while my local DNS address is set in both the fibre router settings page and in the connman settings page and it does survive a reboot, connman does not change the resolv.conf file right away eg: at boot time.
... would be to purge resolvconf and reinstate /etc/resolv.conf as a text file.
I find it quite disturbing that the possible solutions to this absurd situation have to be that blunt (so to speak).
We should be able to set the application to do as we want instead of forcefully blocking it from doing something we do not want it to do as is the case with changing the attributes of a file and deleting a working symlink.
Does not speak well of whoever wrote connman and decided that it was a good thing to so.
@ralph.ronnquist
I don't have the resolveconf package installed. so the etc/resolve.conf -> /run/connman/resolv.conf was set up by connman.
~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 24 Sep 18 06:48 /etc/resolv.conf -> /run/connman/resolv.conf
~$
So there's no resolveconf to purge.
I'd appreciate instructions on how to proceed with your solution.
---
Edit:
I found this this tidbit from 2015 (!) when this mess was already a thing on the web.
... a patch for connman that prevents it from changing resolv.conf, but you'll have to recompile it from source and use it on your own risk.
... another option - to protect your /etc/resolv.conf file using the chattr command:
chattr +i /etc/resolv.conf
A patch?
Recompile and use at your own risk?
Talk about blunt.
Unless I am far off, it would seem that the option to change /etc/resolv.conf attributes at some time actually worked.
ie: the file was not a symlink, just a text file and chattr +i could actually be used.
But then someone thought it would be a good idea to nip that one in the bud.
Will wonders never cease?
---
Thanks in advance.
Best,
A.
Last edited by Altoid (2024-09-18 10:55:14)
Offline
Try chattr -i on the file the symlink points to. That might work.
Or (as root):
ls -l /etc/resolv.conf
# Note where it points to (I'll use dest below).
rm /etc/resolv.conf
mv dest /etc/resolv.conf
That should turn /etc/resolv.conf back into a normal file.
Offline
Hello:
All this crap has me so annoyed.
It has kept me looking all over the web for anything related to connman+resolv.conf.
There are a great many posts complaining about this same issue, going back as far as 2017 ...
I did find an interesting tidbit with respect to the origins of connman and networkmanager which I could not have imagined.
ConnMan is a product of Intel, and NetworkManager is a product of RedHat.
--- snip ---
Who would have guessed?
Those two heavyweights behind a simple application ...
[tin foil]
Make me wonder just much interest they would have in other (competing?) and much less complicated not to mention unobtrusive applications such as WiCD failing or simply just being abandoned. Because, besides connman, networkmanager and WiCD ...
What else is there for Linux?
[/tin foil]
I also found the same opinion/idea already seen in a few forums:
Whoever set up ConnMan figures that the sysadmin has no knowledge of use, and so it does everything itself.
See here.
Also a couple of possible solutions:
When connmanctl borks up whatever symlink /etc/resolv.conf points to this week, particularly with ipv6 nonsense, you can easily set it back to the real nameservers:
# select config id of currently connected network current="$( connmanctl services | awk '/^[^ ]/ && $1~/R/{print $3}' )" connmanctl config "${current}" --nameservers 192.168.1.10 192.168.1.11
Or you could just clobber the resolv.conf with a real file and not a symlink to /etc/connman/resolv.conf. Crap like this makes me miss wicd although I'm sure it had its problems too.
See here.
This last one (originally suggested by Ralph.Ronnquist) is what I am interested in doing but I was not so sure as to how to go about it.
Then I found man connman.conf with the explanation to an an entry I had not seen/noticed before and which could be a solution:
FILE FORMAT
The configuration file consists of sections (groups) of key-value pairs.
--- snip ---
Description of sections and available keys follows:[General]
This section is the only mandatory section of the configuration file.
--- snip ---
ResolvConf=string
Path to resolv.conf file. If the file does not exist, but intermediate directories exist, it will be created. If this option is not set, it tries to write into /run/connman /resolv.conf and fallbacks to /etc/resolv.conf if it fails (/run/connman does not exist or is not writeable). If you do not want to update resolv.conf, you can set /dev/null*.
* underlining is mine
See here.
But it happens that the entry for etc/connman/main.conf mentioned above is not present in that file so I think that the best go-to solution would be to clobber the resolv.conf with a real file and not a symlink to /etc/connman/resolv.conf. ie: blunt force, like with a kitchen roach.
Curiously enough, although I have had my box on-line for almost nine hours, so far there has not been a DNS change (!).
So I really do not have a clue as to what is going on with connman or how it decides when to do what it does.
Truth be told, I just want WiCD back. 8^°
Thank your for the instructions, I was thinking of doing more or less the same thing.
What kept me back is the assumption that as it had been set up by connman doing so would break it and things would get worse.
I will wait and see what happens / till I get another DNS change from connman and then proceed.
Thank you very much for your input.
Best,
A.
Offline
Well, I have looked at two of my PCs with Daedalus: as well on my Ryzen workstation as on my travelling laptop I have a file /etc/resolv.conf, no symlink. And the entry in the file points to my local ethernet router IP as DNS (I am working with fixed IP adresses).
On the laptop I have the Gnome network manager installed to be able to switch between LAN and Wifi and Home and away.
Offline
Hello:
... my PCs with Daedalus ...
... have a file /etc/resolv.conf, no symlink.
I see ...
I take it that this is with connman 1.41-3 installed and modifications to the symlink from you.
Yes?
... file points to my local ethernet router IP as DNS (I am working with fixed IP adresses).
Yes, I think you can set it up with up to two different DNS servers.
Thanks for your input.
Best,
A.
Last edited by Altoid (2024-09-18 20:17:58)
Offline
connman isn't installed on my workstation, it just has LAN:
# apt list connman
Auflistung… Fertig
connman/stable 1.41-3 amd64
connman/stable 1.41-3 i386
I had no need for any network management here.
And I haven't manipulated anything regarding any symlink to /etc/resolv.conf, just entered my local ethernet router's IP.
Last edited by rolfie (2024-09-18 19:43:46)
Offline
Hello:
connman isn't installed on my workstation ...
... it just has LAN
I see ...
When I left a shared WiFi arrangement to get an ADSL and then went on to fibre, I kept WiCD and a network management application (whatever came with Daedalus as default when I upgraded from Beowulf/Chimaera) just to be able to use a wifi spot nearby, just in case fibre goes down.
But 99% of the time I am using LAN, just like you.
Maybe I should look into doing just that ... 8^°
If you could share your how-to I'd be very obliged.
Thanks in advance.
Best,
A.
Last edited by Altoid (2024-09-18 20:30:08)
Offline
Well, my workstation is a new installation (multiboot, paralell to a working Chimaera) of an early Daedalus preview before the release, no upgrade. Simple netinstall, fixed IP, just basic system utilities. AFAIK I just checked the resolv.conf, and did not need to change it. Manual installation of xorg, lightdm and cinnamon with --no-install-recommends, and everything else just as I needed it. No network manager at all.
Offline
When you say "no network manager at all" you actually mean "just using ifupdown". That is the traditional network management which is configured by means of a text editor to edit its configuration files... It is indeed the simplest and easiest way with maximal flexibility.
Offline
I'm still using ifupdown, and agree that it's the easiest with maximal flexibility. The other network managers just get in my way.
Offline
When you say "no network manager at all" you actually mean "just using ifupdown".
... Whatever got installed with cinnamon with --no-install-recommends, no additional packages.
Offline
To be honest, I've never had a problem with connman.
Offline
Hello:
What is going on?
Getting back on track as per my OP.
1.
any NetworkManager files present in my system while that package was not installed can only be adscribed to remnants from either Jesse or ascii - cannot come up with any other explanation.
2.
evidently both NetworkManager and connman take the liberty of screwing around with /etc/resolv.conf which explains the banner left behind by the first.
With respect to whatever/however it is that connman screws around with /etc/resolv.conf, I have not been able to find a clear answer.
Yes, it does edit/replace the file but when and why is still a mystery.
To wit:
Applying chattr +i as sudo/root did not work and connman kept on changing my local DNS setting for my FO provider's.
This in spite of the local DNS address being set both in the FO provider's router and in the connman settings page.
And then, all of a sudden ...
... It has stopped doing it.
Why?
No idea.
Maybe it has a mind of its own? 8^°
The thing is that my local DNS setting has remained as required by me for ~ 48 hours and survived at least a half dozen reboots.
If it acts up again, I will just nuke the symlink and reinstate /etc/resolv.conf as a text file.
But still ...
I am not at all happy with not knowing what is going and exactly why.
Much less with applying brute force (chattr +i) to keep it from happening.
So I am planning to approach the solution suggested by Ralph.Ronnquist: use ifupdown.
I found an interesting page with what seem to be a set of comprehensive instructions to make the conversion to ifupdown.
But I'll have to study them before taking any action but I think it is definitely a step in the right direction.
Thank you very much to all those who pitched in.
Marking this one solved.
Best,
A.
Last edited by Altoid (2024-10-09 11:26:04)
Offline
I know this topic's "solved." I just have a comment related to something that you brought up a few times in this thread, and that's wicd. A few weeks ago (maybe a month, it's hard to keep track of time), during some periods of spare time, I attempted to get wicd to run on python3 with devuan daedalus. Made a fair amount of progress, but as of yet it is still nonfunctional. Haven't messed with it for probably 2 weeks now, but I may return to it, if/when I have the time. There's a lot of things that have changed with python and gtk... and I'm not a python programmer so some parts are a bit confusing. I primarily use my desktop on wired network anyway, no real need for network-manager or connman or wicd there.
Offline
@rbit . . . Check out this post:
FWIW, I am also a wired user but still miss wicd.
Offline
Thanks for that, golinux. (btw your link is off, but I found the post from the title. just add a "2" to the end of your link -- id=6842).
:-)
Offline
@rbit . . . Thanks for catching that. Fixed . . .
Offline
Main:It seems like you have a conflict between Connman and NetworkManager.Connman often runs in the background, even if NetworkManager is active Try uninstalling Connman if you don’t need it: apt remove connman.Then check if /etc/resolv.conf is still being rewritten.Supplement:I had a similar issue after an upgrade.WiCD can also cause confusion if it was previously installedCheck what’s running: systemctl status NetworkManager.
Offline
Hello:
... a conflict between Connman and NetworkManager ...
No, not that.
Turns out that NetworkManager at some time in the distant past, left a few remnants.
It was not installed and hence not running. See post #1.
... check if /etc/resolv.conf is still being rewritten.
Well ...
That is the mystery still afoot.
Since my last post, my box has been rebooted no less that 3 / 4 times a day for the last week or so.
And for all those reboots and time it was on-line (up to seven hours a day) connman has (knock wood) seen it fit to leave my /etc/resolv.conf alone.
But here's the thing®: I have no idea why.
ie: attempting to apply +i chattr to /etc/resolv.conf, tis last file being a symlink to /var/run/connman//etc/resolv.conf only gets an error message.
So I don't think what seemed to be the accepted solution took hold.
... running: systemctl status NetworkManager.
Hmm ...
systemctl? -> surely you jest ...
Thanks for your input.
Best,
A.
Offline
Try df -k /var/run/ and ls -lid /var/run
On my system /var/run/ is a symlink to /run which is a tmpfs. So it's contents will be re-created at every reboot, which will make the -i flag vanish (tmpfs is a filesystem that only exists in ram).
That would explain why chattr -i didn't seem to work. Checking with lsattr might be interesting too.
Offline
Hello:
... df -k /var/run/ and ls -lid /var/run
Like you said:
~$ df -k /var/run
Filesystem 1K-blocks Used Available Use% Mounted on tmpfs # tmpfs
806412 832 805580 1% /run
~$
~$ ls -lid /var/run
913937 lrwxrwxrwx 1 root root 4 May 21 2017 /var/run -> /run # symlink
~$
~$ lsattr /etc/resolv.conf
lsattr: Operation not supported While reading flags on /etc/resolv.conf # same error with [chattr +i]
~$
~$ lsattr /var/run/connman/resolv.conf
---------------------- /var/run/connman/resolv.conf
~$
~$ lsattr /run/connman/resolv.conf
---------------------- /run/connman/resolv.conf
~$
Like I said before, with respect to connman and what it does with /etc/resolv.conf:
I am not at all happy with not knowing what is going and exactly why.
Thanks for your input.
Best,
A.
Offline