pcalvert wrote: For anyone who is running connman and having this problem, there is a simple fix.

DAEMON=/usr/sbin/connmand
DAEMON_OPTS='--nodnsproxy'
DESC="Connection Manager"

Yes it is!

Thanks a million, i have a lot of older drives here and there, a mess actually and needed a fix I could just use from an USB drive.

Appreciate the share!

cheers

zephyr

I use Ceres and update most days but never seen that problem before. Except yesterday..

I maintain a friend's machines which run chimaera (and use provider DNS):

Temporary failure resolving 'deb.devuan.org'

Immediately after editing resolv.conf with a known good alternative DNS server, all was well.

Later, at my own machine, again no problem. Why is that?

For anyone who is running connman and having this problem, there is a simple fix.

Edit this file: /etc/init.d/connman

Change this:

DAEMON=/usr/sbin/connmand
DESC="Connection Manager"

To this:

DAEMON=/usr/sbin/connmand
DAEMON_OPTS='--nodnsproxy'
DESC="Connection Manager"

Reboot.

pcalvert's solution worked for me. No DNS changes, resolv.conf updates, or network manager changes needed.

One thing I noted, it did a kernel update for me, but did not automatically swap to the new kernel on re-boot, went to delete the old kernel after re-boot, got warnings from Synaptic which I foolishly ignored, then wouldn't boot back up, had to go into advanced options on the grub screen and manually enter new kernel, first time i've ever had to do this, wonder why?

Regards.

P.S.

 localhost:/ # /usr/sbin/traceroute deb.devuan.org
traceroute to deb.devuan.org (141.84.43.19), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  2.568 ms  3.567 ms  4.584 ms
 2  100.67.123.1 (100.67.123.1)  9.859 ms  9.942 ms  10.269 ms
 3  100.127.249.225 (100.127.249.225)  10.348 ms  10.772 ms  11.988 ms
 4  100.127.243.233 (100.127.243.233)  11.092 ms  11.573 ms  11.152 ms
 5  100.127.241.129 (100.127.241.129)  15.257 ms  16.245 ms  16.334 ms
 6  100.127.241.109 (100.127.241.109)  16.949 ms  9.811 ms  9.820 ms
 7  ae0-420.RT.NTL.KIV.UA.retn.net (87.245.237.4)  16.536 ms  16.631 ms  44.538 ms
 8  ae4-9.RT.IPB.BER.DE.retn.net (87.245.233.39)  31.865 ms  32.217 ms ae2-9.RT.IPB.BER.DE.retn.net (87.245.233.47)  33.883 ms
 9  dfn.bcix.de (193.178.185.42)  34.434 ms  36.258 ms  36.098 ms
10  cr-erl2-be7.x-win.dfn.de (188.1.146.209)  45.251 ms  46.979 ms  46.820 ms
11  cr-gar1-be3.x-win.dfn.de (188.1.144.214)  51.299 ms  51.810 ms  51.628 ms
12  * * *
13  vl-3002.csr4-kb1.lrz.de (129.187.0.134)  45.573 ms  44.651 ms  45.704 ms
14  vl-3011.csr2-kic.lrz.de (129.187.0.154)  44.403 ms  45.459 ms  45.456 ms
15  * * *
16  * * *
 

Considering the geography and the fact that deb.devuan.org is located in Germany, it is possible and makes sense to indicate the specific address of the nearest mirror.
But this is the decision of the user himself.

pkgmaster.devuan.org serves packages. It's repository (both the devuan-only and the merged parts) is also mirrored to several other servers, and the domain name "deb.devuan.org" is used to obtain all IP addresses for all those (inkluding pkgmaster.devuan.org).

Of course, DNS resolution is a separate subsystem that mostly doesn't involve devuan servers except for eventually and intemittently obtaining that resolution list for deb.devaun.org, which nameservers here and there digests into their cache for the in-between-times resolution service.

All in all, the most problems arise in the DNS resolution sub system; it almost never leads back to hickups with the cllient networking software. Usually due to the DNS subsystem being in transition with intermediate servers being updated. On occasion there are also transient inconcistencies in downloads due to the meta files have been updated on the actual server queried for those before the package pool of the actual server queried for those.

Edit this file: /etc/init.d/connman

Change this:

DAEMON=/usr/sbin/connmand
DESC="Connection Manager"

To this:

DAEMON=/usr/sbin/connmand
DAEMON_OPTS='--nodnsproxy'
DESC="Connection Manager"

Reboot.

In my experience, this issue with deb.devuan.org in the sources.list used to happen maybe once or twice a year? I can't remember since it's so infrequent...plus...I'm amnesiactical...

It's stable after all. In my lowly opinion, the only pressing issue would be if a user was trying to install a package from the repos under those circumstances...I don't think waiting a few days (for an issue like this to be resolved) would be a detriment to security on a stable system, but I digress.

...or...the user could try changing their sources.list or installing a different "network-manager" so as not to have to worry about it in the future???

And second, of course, you can specify a specific address in sources.list, having first checked it.

root@devuan:/# ping deb.devuan.org
PING deb.rr.devuan.org (130.225.254.116) 56(84) bytes of data.
64 bytes from mirrors.dotsrc.org (130.225.254.116): icmp_seq=1 ttl=53 time=54.0 ms
64 bytes from mirrors.dotsrc.org (130.225.254.116): icmp_seq=2 ttl=53 time=54.1 ms
64 bytes from mirrors.dotsrc.org (130.225.254.116): icmp_seq=3 ttl=53 time=54.3 ms
64 bytes from mirrors.dotsrc.org (130.225.254.116): icmp_seq=4 ttl=53 time=53.9 ms
64 bytes from mirrors.dotsrc.org (130.225.254.116): icmp_seq=5 ttl=53 time=53.5 ms
64 bytes from mirrors.dotsrc.org (130.225.254.116): icmp_seq=6 ttl=53 time=54.4 ms
^C
--- deb.rr.devuan.org ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 9078ms
rtt min/avg/max/mdev = 53.546/54.054/54.401/0.289 ms
root@devuan:/# ping dev.beard.ly
PING dev.beard.ly (198.58.118.8) 56(84) bytes of data.
64 bytes from dev.beard.ly (198.58.118.8): icmp_seq=1 ttl=45 time=162 ms
64 bytes from dev.beard.ly (198.58.118.8): icmp_seq=2 ttl=45 time=161 ms
64 bytes from dev.beard.ly (198.58.118.8): icmp_seq=3 ttl=45 time=161 ms
^C
--- dev.beard.ly ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 161.072/161.386/161.805/0.308 ms
root@devuan:/#   

caja

It's just my experience that deb.devuan.org has hiccups every now-and-then.

Glad everything is working for you now.