My wired connection doesn't work suddenly (Debian sid)

[Vinícius Couto]

Hi,

I use Debian sid and some weeks ago, a upgrade in some package caused a
strange thing.

I use my computer, when my wired connection down. Sometimes only the IPv4,
sometimes all the connections.
The symbol of the wired connection says that the connection is working.
When i disable to use a wireless connection in the same network, it works.


When i use dmesg | grep r8169
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:02:00.0 eth0: RTL8168evl/8111evl at 0x (ptrval), ..., XID
... IRQ ..
r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx
checksumming: ko]
r8169 0000:02:00.0 enp2s0: renamed from eth0
r8169 0000:02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168e-3.fw

dmesg | grep enp2s0
TCP: enp2s0: Driver has suspect GRO implementation, TCP performance may be
compromised.

What is happening to my computer?

Reggard,

[Reco]

Hi.

Post by Vinícius Couto
Hi,
I use Debian sid and some weeks ago, a upgrade in some package caused a
strange thing.
I use my computer, when my wired connection down. Sometimes only the IPv4,
sometimes all the connections.

Yet another NetworkManager fault, most likely. The thing lives to its
reputation once more.

Post by Vinícius Couto
The symbol of the wired connection says that the connection is working.
When i disable to use a wireless connection in the same network, it works.

Of all the ways to test network connection you just used the least
informative one. Please share the output of "ip a l" and "ip ro l" next
time this happens.

Post by Vinícius Couto
When i use dmesg | grep r8169
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:02:00.0 eth0: RTL8168evl/8111evl at 0x (ptrval), ..., XID
... IRQ ..
r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx
checksumming: ko]

Pretty normal.

Post by Vinícius Couto
r8169 0000:02:00.0 enp2s0: renamed from eth0

That's systemd thing.

Post by Vinícius Couto
r8169 0000:02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168e-3.fw

And here you've used non-free blob, which is most likely completely
unnecessary. But it's unlikely that any of these are somehow related to
your problem.

Post by Vinícius Couto
dmesg | grep enp2s0
TCP: enp2s0: Driver has suspect GRO implementation, TCP performance may be
compromised.

And that says that your NIC has problematic Generic Receive Offload
implementation, yet kernel enabled it.
Try "ethtool -K enp2s0 gro off" if it bothers you, but it'll unlikely
will have any visible effect.

Post by Vinícius Couto
What is happening to my computer?

Network Manager. See above.

Reco

[Gene Heskett]

Post by Reco
Hi.

Post by Vinícius Couto
Hi,
I use Debian sid and some weeks ago, a upgrade in some package
caused a strange thing.
I use my computer, when my wired connection down. Sometimes only the
IPv4, sometimes all the connections.

Yet another NetworkManager fault, most likely. The thing lives to its
reputation once more.

Post by Vinícius Couto
The symbol of the wired connection says that the connection is
working. When i disable to use a wireless connection in the same
network, it works.

Of all the ways to test network connection you just used the least
informative one. Please share the output of "ip a l" and "ip ro l"
next time this happens.

Why do I have to read a mailing list to learn how to use these new ip
tools. Those two examples tell me more than than 20 readings of the man
page, thank you Reco.

Post by Reco

Post by Vinícius Couto
When i use dmesg | grep r8169
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:02:00.0 eth0: RTL8168evl/8111evl at 0x (ptrval),
..., XID ... IRQ ..
r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 bytes, tx
checksumming: ko]

Pretty normal.

Post by Vinícius Couto
r8169 0000:02:00.0 enp2s0: renamed from eth0

That's systemd thing.

Post by Vinícius Couto
r8169 0000:02:00.0: firmware: direct-loading firmware
rtl_nic/rtl8168e-3.fw

And here you've used non-free blob, which is most likely completely
unnecessary. But it's unlikely that any of these are somehow related
to your problem.

Post by Vinícius Couto
dmesg | grep enp2s0
TCP: enp2s0: Driver has suspect GRO implementation, TCP performance
may be compromised.

And that says that your NIC has problematic Generic Receive Offload
implementation, yet kernel enabled it.
Try "ethtool -K enp2s0 gro off" if it bothers you, but it'll unlikely
will have any visible effect.

Post by Vinícius Couto
What is happening to my computer?

Network Manager. See above.
Reco

Rant mode ON

What I have never understood about N-M is why it tears down a perfectly
good, working connection, and spends 5 minutes trying to establish a new
one, and failing, leaving the poor user no way to ask a mailing list for
help. Thats unforgivable and unforgiven here. Theres some keywords
(mentioned in the man page in obtuse language IIRC) to use in e-n-i to
tell N_M to keep its malicious hands off a given interface, but you have
to read between the lines with your logical superpowers to detect them.
There now, but for the longest time removing its starter script via
chkconfig or removing N-M with the package manager, not possible a
decade ago without its dependencies tearing down the system so I used mc
for that, nuking the binaries. So its getting better, but as can be seen
above its not perfect yet for folks needing portability. And I've used
WICD for that in past years when I needed my old lappy to give me email
and browsing from a motel room 950 miles from home while I was out
playing visiting tv engineer. But my old lappy has a busted bcm4318
based radio that not even the windows xp drivers could make work, so I'm
glad the motel had radios I could plug into its net port.

Thanks for reading this far.

/Rant mode OFF

[Pascal Hambourg]

Post by Gene Heskett
Why do I have to read a mailing list to learn how to use these new ip
tools.

"New" ? iproute has been around for more that 20 years !

Post by Gene Heskett
Theres some keywords
(mentioned in the man page in obtuse language IIRC) to use in e-n-i to
tell N_M to keep its malicious hands off a given interface, but you have
to read between the lines with your logical superpowers to detect them.

No, there is no obscure keyword and nothing between the lines.
By default, NM does not manage any interface configured in
/etc/network/interfaces. So all you have to do is configure your
interface with an "iface" stanza in /etc/network/interfaces as usual so
that it is managed by ifupdown and not by NM.

[Gene Heskett]

Post by Pascal Hambourg

Post by Gene Heskett
Why do I have to read a mailing list to learn how to use these new
ip tools.

"New" ? iproute has been around for more that 20 years !

Post by Gene Heskett
Theres some keywords
(mentioned in the man page in obtuse language IIRC) to use in e-n-i
to tell N_M to keep its malicious hands off a given interface, but
you have to read between the lines with your logical superpowers to
detect them.

No, there is no obscure keyword and nothing between the lines.

Oh? And you wrote that manpage I suppose, and you don't make mistakes...

You may be able to read it, knowing what you "intended" to write. But
others aren't mind readers.

But we can add 2+2 and get a quite precisely defined 4.0000000000.

Post by Pascal Hambourg
By default, NM does not manage any interface configured in
/etc/network/interfaces. So all you have to do is configure your
interface with an "iface" stanza in /etc/network/interfaces as usual
so that it is managed by ifupdown and not by NM.

I have had N-M tear down a well configured staticly defined eth0 on
dozens of occasions, despite using the iface designation in my e-n-i's.
Most recently on a stretch install on a rock64 I had to erect immutable
attributes to resolv.conf after making it a real file, and e-n-i to make
networking Just Work.

It may not do it today, things do get improved but my linux experience
dates to RH5.0 and 1998 and its been something I've had to edit e-n-i
and then quickly make it immutable, ditto for making /etc/resolv.conf a
real file and immutable ever since N-M was made virtually mandatory. My
networking is not portable and with the exception of my ancient lappy
will never be.

Theres a reason my /etc/hosts files are 20+ lines long, and my
resolv.conf has a "search hosts nameserver" line in it, which N-M always
removes if it can. The real file, made immutable fixes that too

N-M is helpless when there is not a dhcp server or a dhcp server that
only recognizes the MAC of one machine for security reasons.

Based on my experience at making N-M work, you might want to get a
shorter horse.

[Pascal Hambourg]

Post by Gene Heskett

Post by Pascal Hambourg

Post by Gene Heskett
Theres some keywords
(mentioned in the man page in obtuse language IIRC) to use in e-n-i
to tell N_M to keep its malicious hands off a given interface, but
you have to read between the lines with your logical superpowers to
detect them.

No, there is no obscure keyword and nothing between the lines.

Oh? And you wrote that manpage I suppose, and you don't make mistakes...

Irrelevant.

Post by Gene Heskett
You may be able to read it, knowing what you "intended" to write. But
others aren't mind readers.

Maybe I was not clear enough. Let me rephrase a bit.

Contrary to what you wrote, there is no obscure keyword to use in
/etc/network/interfaces to tell NetworkManager to keep its hands off a
given interface.

Post by Gene Heskett

Post by Pascal Hambourg
By default, NM does not manage any interface configured in
/etc/network/interfaces. So all you have to do is configure your
interface with an "iface" stanza in /etc/network/interfaces as usual
so that it is managed by ifupdown and not by NM.

I have had N-M tear down a well configured staticly defined eth0 on
dozens of occasions, despite using the iface designation in my e-n-i's.

Then it is a bug which should be reported and fixed. It is not intended
behaviour.

Post by Gene Heskett
Most recently on a stretch install on a rock64 I had to erect immutable
attributes to resolv.conf after making it a real file, and e-n-i to make
networking Just Work.

/etc/resolv.conf is a rather different topic, because it is not related
to a specific interface and may be written by several pieces of
software, including but not limited to NetworkManager when configuring
*any* interface. I would suggest using resolvconf but I suspect you
would not like it either.

[Gene Heskett]

Post by Pascal Hambourg

Post by Gene Heskett

Post by Pascal Hambourg

Post by Gene Heskett
Theres some keywords
(mentioned in the man page in obtuse language IIRC) to use in
e-n-i to tell N_M to keep its malicious hands off a given
interface, but you have to read between the lines with your
logical superpowers to detect them.

No, there is no obscure keyword and nothing between the lines.

Oh? And you wrote that manpage I suppose, and you don't make
mistakes...

Irrelevant.

If you didn't write it, I apologize for venting at the wrong person.

Post by Pascal Hambourg

Post by Gene Heskett
You may be able to read it, knowing what you "intended" to write.
But others aren't mind readers.

Maybe I was not clear enough. Let me rephrase a bit.
Contrary to what you wrote, there is no obscure keyword to use in
/etc/network/interfaces to tell NetworkManager to keep its hands off a
given interface.

Post by Gene Heskett

Post by Pascal Hambourg
By default, NM does not manage any interface configured in
/etc/network/interfaces. So all you have to do is configure your
interface with an "iface" stanza in /etc/network/interfaces as
usual so that it is managed by ifupdown and not by NM.

I have had N-M tear down a well configured staticly defined eth0 on
dozens of occasions, despite using the iface designation in my e-n-i's.

Then it is a bug which should be reported and fixed. It is not
intended behaviour.

Any fusses I have posted to bugzilla have all been "won't fix" in just a
few minutes. You'd think its tailor was Dupont. Teflon suits IOW.

Post by Pascal Hambourg

Post by Gene Heskett
Most recently on a stretch install on a rock64 I had to erect
immutable attributes to resolv.conf after making it a real file, and
e-n-i to make networking Just Work.

/etc/resolv.conf is a rather different topic, because it is not
related to a specific interface and may be written by several pieces
of software, including but not limited to NetworkManager when
configuring *any* interface. I would suggest using resolvconf but I
suspect you would not like it either.

Ohkaay, but where's the docs on this mysterious resolvconf?

What we do have is missing (wheezy) or horribly incomplete (jessie).

But I'll have to take that back, my apologies. I just read the stretch
version on that rock64. And as man pages go, its decent. And I'll have
to do some experimenting as its possible I can train it to behave.

And curious I blink compared the jessie vs stretch versions, stretch's is
both longer AND more complete, and two different authors and formatted
completely different. And wheezy doesn't even have the man page. I don't
even know if it should, maybe not for wheezy, lots of water has been
recycled since those installs were made, so I'll plead oldtimers.

[David Wright]

Post by Gene Heskett

Post by Pascal Hambourg

Post by Gene Heskett
Most recently on a stretch install on a rock64 I had to erect
immutable attributes to resolv.conf after making it a real file, and
e-n-i to make networking Just Work.

/etc/resolv.conf is a rather different topic, because it is not
related to a specific interface and may be written by several pieces
of software, including but not limited to NetworkManager when
configuring *any* interface. I would suggest using resolvconf but I
suspect you would not like it either.

Ohkaay, but where's the docs on this mysterious resolvconf?
What we do have is missing (wheezy) or horribly incomplete (jessie).
But I'll have to take that back, my apologies. I just read the stretch
version on that rock64. And as man pages go, its decent. And I'll have
to do some experimenting as its possible I can train it to behave.
And curious I blink compared the jessie vs stretch versions, stretch's is
both longer AND more complete, and two different authors and formatted
completely different. And wheezy doesn't even have the man page. I don't
even know if it should, maybe not for wheezy, lots of water has been
recycled since those installs were made, so I'll plead oldtimers.

This is very strange. I just did (in 80 column xterms):

$ man resolvconf > /tmp/resolvconf-stretch

and the same for jessie and wheezy on the appropriate computers.

$ diff /tmp/resolvconf-[sj]*
3,4d2
<
<
278d275
<
295,296d291
<
<
$

so a few blank lines have been removed between jessie and stretch.
As for wheezy not having a man page:

$ wc /tmp/resolvconf-wheezy
301 1748 14876 /tmp/resolvconf-wheezy
$ cat /etc/debian_version
7.11
$ dpkg -l resolvconf
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===================-==============-==============-===========================================
ii resolvconf 1.67 all name server information handler
$ dpkg -L resolvconf | grep /man./
/usr/share/man/man8/resolvconf.8.gz
/usr/share/man/man5/interface-order.5.gz
$

So one can't help wondering exactly what is installed on your machines
if things don't match. Note that there are significant differences
between the different versions, so following the stretch/jessie man
page could give you problems on a wheezy machine. (I haven't checked
out backports.)

Cheers,
David.

[Gene Heskett]

Post by David Wright

Post by Gene Heskett

Post by Pascal Hambourg

Post by Gene Heskett
Most recently on a stretch install on a rock64 I had to erect
immutable attributes to resolv.conf after making it a real file,
and e-n-i to make networking Just Work.

/etc/resolv.conf is a rather different topic, because it is not
related to a specific interface and may be written by several
pieces of software, including but not limited to NetworkManager
when configuring *any* interface. I would suggest using resolvconf
but I suspect you would not like it either.

Ohkaay, but where's the docs on this mysterious resolvconf?
What we do have is missing (wheezy) or horribly incomplete (jessie).
But I'll have to take that back, my apologies. I just read the
stretch version on that rock64. And as man pages go, its decent.
And I'll have to do some experimenting as its possible I can train
it to behave.
And curious I blink compared the jessie vs stretch versions,
stretch's is both longer AND more complete, and two different
authors and formatted completely different. And wheezy doesn't even
have the man page. I don't even know if it should, maybe not for
wheezy, lots of water has been recycled since those installs were
made, so I'll plead oldtimers.

$ man resolvconf > /tmp/resolvconf-stretch
and the same for jessie and wheezy on the appropriate computers.
$ diff /tmp/resolvconf-[sj]*
3,4d2
<
<
278d275
<
295,296d291
<
<
$
so a few blank lines have been removed between jessie and stretch.
$ wc /tmp/resolvconf-wheezy
301 1748 14876 /tmp/resolvconf-wheezy
$ cat /etc/debian_version
7.11
$ dpkg -l resolvconf
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/T
|rig-pend / Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
|
||/ Name Version Architecture Description
+++-===================-==============-==============-================
=========================== ii resolvconf 1.67 all
name server information handler $ dpkg -L resolvconf | grep
/man./
/usr/share/man/man8/resolvconf.8.gz
/usr/share/man/man5/interface-order.5.gz
$
So one can't help wondering exactly what is installed on your machines
if things don't match. Note that there are significant differences
between the different versions, so following the stretch/jessie man
page could give you problems on a wheezy machine. (I haven't checked
out backports.)
Cheers,
David.

What is installed on 4 of the 6 boxes here, is a wheezy install thats
been tweaked to A: put a realtime kernel on it so it can run linuxcnc on
real hardware. The stretch I'll install here after my new drive cage
arrives, and I found today that newegg's fedex is a week for delivery,
its not expected to arrive here before Thursday evening, has also been
tweaked to run LinuxCNC, probably by a real time kernel replacement..

Thanks David, gotta run the mussus just called on the intercom. Later.

[David Wright]

Post by Gene Heskett

Post by David Wright

Post by Gene Heskett

Post by Pascal Hambourg

Post by Gene Heskett
Most recently on a stretch install on a rock64 I had to erect
immutable attributes to resolv.conf after making it a real file,
and e-n-i to make networking Just Work.

/etc/resolv.conf is a rather different topic, because it is not
related to a specific interface and may be written by several
pieces of software, including but not limited to NetworkManager
when configuring *any* interface. I would suggest using resolvconf
but I suspect you would not like it either.

Ohkaay, but where's the docs on this mysterious resolvconf?
What we do have is missing (wheezy) or horribly incomplete (jessie).
But I'll have to take that back, my apologies. I just read the
stretch version on that rock64. And as man pages go, its decent.
And I'll have to do some experimenting as its possible I can train
it to behave.
And curious I blink compared the jessie vs stretch versions,
stretch's is both longer AND more complete, and two different
authors and formatted completely different. And wheezy doesn't even
have the man page. I don't even know if it should, maybe not for
wheezy, lots of water has been recycled since those installs were
made, so I'll plead oldtimers.

[snipped various properties of resolvconf's man page on wheezy/jessie/stretch.]

Post by Gene Heskett

Post by David Wright
So one can't help wondering exactly what is installed on your machines
if things don't match. Note that there are significant differences
between the different versions, so following the stretch/jessie man
page could give you problems on a wheezy machine. (I haven't checked
out backports.)

What is installed on 4 of the 6 boxes here, is a wheezy install thats
been tweaked to A: put a realtime kernel on it so it can run linuxcnc on
real hardware. The stretch I'll install here after my new drive cage
arrives, and I found today that newegg's fedex is a week for delivery,
its not expected to arrive here before Thursday evening, has also been
tweaked to run LinuxCNC, probably by a real time kernel replacement..

Which kernel you run should have no connection with the contents of
Debian's resolvconf packages. You should still have these three:

4575 Jun 19 2012 /usr/share/man/man8/resolvconf.8.gz
4500 Jan 27 2015 /usr/share/man/man8/resolvconf.8.gz
4500 May 19 2016 /usr/share/man/man8/resolvconf.8.gz

Cheers,
David.

[Gene Heskett]

Post by David Wright

Post by Gene Heskett

Post by David Wright

Post by Gene Heskett

Post by Pascal Hambourg

Post by Gene Heskett
Most recently on a stretch install on a rock64 I had to
erect immutable attributes to resolv.conf after making it a
real file, and e-n-i to make networking Just Work.

/etc/resolv.conf is a rather different topic, because it is
not related to a specific interface and may be written by
several pieces of software, including but not limited to
NetworkManager when configuring *any* interface. I would
suggest using resolvconf but I suspect you would not like it
either.

Ohkaay, but where's the docs on this mysterious resolvconf?
What we do have is missing (wheezy) or horribly incomplete (jessie).
But I'll have to take that back, my apologies. I just read the
stretch version on that rock64. And as man pages go, its
decent. And I'll have to do some experimenting as its possible I
can train it to behave.
And curious I blink compared the jessie vs stretch versions,
stretch's is both longer AND more complete, and two different
authors and formatted completely different. And wheezy doesn't
even have the man page. I don't even know if it should, maybe
not for wheezy, lots of water has been recycled since those
installs were made, so I'll plead oldtimers.

[snipped various properties of resolvconf's man page on
wheezy/jessie/stretch.]

Post by Gene Heskett

Post by David Wright
So one can't help wondering exactly what is installed on your
machines if things don't match. Note that there are significant
differences between the different versions, so following the
stretch/jessie man page could give you problems on a wheezy
machine. (I haven't checked out backports.)

What is installed on 4 of the 6 boxes here, is a wheezy install
thats been tweaked to A: put a realtime kernel on it so it can run
linuxcnc on real hardware. The stretch I'll install here after my
new drive cage arrives, and I found today that newegg's fedex is a
week for delivery, its not expected to arrive here before Thursday
evening, has also been tweaked to run LinuxCNC, probably by a real
time kernel replacement..

Which kernel you run should have no connection with the contents of
4575 Jun 19 2012 /usr/share/man/man8/resolvconf.8.gz
4500 Jan 27 2015 /usr/share/man/man8/resolvconf.8.gz
4500 May 19 2016 /usr/share/man/man8/resolvconf.8.gz

not on any wheezy sourced from the linuxcnc install iso, David

My /etc/resolv.conf is a real file and looks something like this:

nameserver 192.168.71.1
search hosts nameserver

And it Just Works.

Post by David Wright
Cheers,
David.

[Timothy M Butterworth]

Post by Gene Heskett

Post by David Wright

Post by Gene Heskett

Post by David Wright

Post by Gene Heskett

Post by Pascal Hambourg

Post by Gene Heskett
Most recently on a stretch install on a rock64 I had to
erect immutable attributes to resolv.conf after making it a
real file, and e-n-i to make networking Just Work.

/etc/resolv.conf is a rather different topic, because it is
not related to a specific interface and may be written by
several pieces of software, including but not limited to
NetworkManager when configuring *any* interface. I would
suggest using resolvconf but I suspect you would not like it
either.

Ohkaay, but where's the docs on this mysterious resolvconf?
What we do have is missing (wheezy) or horribly incomplete (jessie).
But I'll have to take that back, my apologies. I just read the
stretch version on that rock64. And as man pages go, its
decent. And I'll have to do some experimenting as its possible I
can train it to behave.
And curious I blink compared the jessie vs stretch versions,
stretch's is both longer AND more complete, and two different
authors and formatted completely different. And wheezy doesn't
even have the man page. I don't even know if it should, maybe
not for wheezy, lots of water has been recycled since those
installs were made, so I'll plead oldtimers.

[snipped various properties of resolvconf's man page on
wheezy/jessie/stretch.]

Post by Gene Heskett

Post by David Wright
So one can't help wondering exactly what is installed on your
machines if things don't match. Note that there are significant
differences between the different versions, so following the
stretch/jessie man page could give you problems on a wheezy
machine. (I haven't checked out backports.)

What is installed on 4 of the 6 boxes here, is a wheezy install
thats been tweaked to A: put a realtime kernel on it so it can run
linuxcnc on real hardware. The stretch I'll install here after my
new drive cage arrives, and I found today that newegg's fedex is a
week for delivery, its not expected to arrive here before Thursday
evening, has also been tweaked to run LinuxCNC, probably by a real
time kernel replacement..

Which kernel you run should have no connection with the contents of
4575 Jun 19 2012 /usr/share/man/man8/resolvconf.8.gz
4500 Jan 27 2015 /usr/share/man/man8/resolvconf.8.gz
4500 May 19 2016 /usr/share/man/man8/resolvconf.8.gz

not on any wheezy sourced from the linuxcnc install iso, David
nameserver 192.168.71.1
search hosts nameserver
And it Just Works.

Post by David Wright
Cheers,
David.

--
Cheers, Gene Heskett
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Mine is immutable as well. I have Google DNS Configured.

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4888:3b:ff00:3c2:d::
nameserver 2001:4888:32:ff00:3c1:d::

[David Wright]

Post by Gene Heskett

Post by David Wright

Post by Gene Heskett

Post by David Wright

Post by Gene Heskett

Post by Pascal Hambourg

Post by Gene Heskett
Most recently on a stretch install on a rock64 I had to
erect immutable attributes to resolv.conf after making it a
real file, and e-n-i to make networking Just Work.

/etc/resolv.conf is a rather different topic, because it is
not related to a specific interface and may be written by
several pieces of software, including but not limited to
NetworkManager when configuring *any* interface. I would
suggest using resolvconf but I suspect you would not like it
either.

Ohkaay, but where's the docs on this mysterious resolvconf?
What we do have is missing (wheezy) or horribly incomplete (jessie).
But I'll have to take that back, my apologies. I just read the
stretch version on that rock64. And as man pages go, its
decent. And I'll have to do some experimenting as its possible I
can train it to behave.
And curious I blink compared the jessie vs stretch versions,
stretch's is both longer AND more complete, and two different
authors and formatted completely different. And wheezy doesn't
even have the man page. I don't even know if it should, maybe
not for wheezy, lots of water has been recycled since those
installs were made, so I'll plead oldtimers.

That's about the *man pages* for resolvconf.

Post by Gene Heskett

Post by David Wright
[snipped various properties of resolvconf's man page on
wheezy/jessie/stretch.]

Post by Gene Heskett

Post by David Wright
So one can't help wondering exactly what is installed on your
machines if things don't match. Note that there are significant
differences between the different versions, so following the
stretch/jessie man page could give you problems on a wheezy
machine. (I haven't checked out backports.)

What is installed on 4 of the 6 boxes here, is a wheezy install
thats been tweaked to A: put a realtime kernel on it so it can run
linuxcnc on real hardware. The stretch I'll install here after my
new drive cage arrives, and I found today that newegg's fedex is a
week for delivery, its not expected to arrive here before Thursday
evening, has also been tweaked to run LinuxCNC, probably by a real
time kernel replacement..

Which kernel you run should have no connection with the contents of
4575 Jun 19 2012 /usr/share/man/man8/resolvconf.8.gz
4500 Jan 27 2015 /usr/share/man/man8/resolvconf.8.gz
4500 May 19 2016 /usr/share/man/man8/resolvconf.8.gz

Those are the man pages (your "docs") for wheezy/jessie/stretch.
They should be on your various systems according to Debian codename.

Post by Gene Heskett
not on any wheezy sourced from the linuxcnc install iso, David

Well, look again. In /usr/share/man/man8/, not /etc/.

Post by Gene Heskett
nameserver 192.168.71.1
search hosts nameserver
And it Just Works.

Yes, /etc/resolv.conf is not a man page. And I don't suppose your
/etc/resolv.conf is missing from wheezy or horribly incomplete in
jessie, which is what you were claiming for the *docs*.

And note that none of this is about the man page for resolv.conf which
is in section (5) rather than (8) as it's about a file, not a command.
If you read the latter, you'll see that your line "search hosts nameserver"
doesn't make a lot of sense.

But that's a conversation we had last year.
https://lists.debian.org/debian-user/2017/08/msg01432.html

Cheers,
David.