dhcpcd behaviour

Discussion:

dhcpcd behaviour

(too old to reply)

Robert Swindells

2021-10-27 13:09:14 UTC

I just use dhcpcd(8) to handle IPv6 and use static IPv4 addressing on
my local network with a hand-written /etc/resolv.conf.

If I add the upstream network interface to a bridge(4) then the
/etc/resolv.conf file is overwritten with an empty one, this obviously
breaks DNS lookup on that machine.

Any opinions on whether the current behaviour is sensible and the best
place to fix it if it isn't?

Robert Swindells

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Greg Troxel

2021-10-27 13:35:09 UTC

Permalink

Post by Robert Swindells
I just use dhcpcd(8) to handle IPv6 and use static IPv4 addressing on
my local network with a hand-written /etc/resolv.conf.
If I add the upstream network interface to a bridge(4) then the
/etc/resolv.conf file is overwritten with an empty one, this obviously
breaks DNS lookup on that machine.
Any opinions on whether the current behaviour is sensible and the best
place to fix it if it isn't?

Are you telling dhcpcd via its config to not take resolv.conf from DHCP,
via something like

static domain_name=example.com
static domain_name_servers=127.0.0.1

? That seems to be how you tell it not to write resolv.conf from what
comes over DHCP. If you did that and it's still writing an empty one,
that sounds like a bug.

Also, I really don't understand what you are doing. Are you talking
about running dhcpcd on client machines on the local LAN, or on the
machine that serves the LAN and has an ISP interface too, or semothing
else?

Robert Swindells

2021-10-27 14:18:01 UTC

Permalink

Post by Greg Troxel

I'm telling it via the command line supplied from /etc/rc.conf
with dhcpcd_flags="-6 --nodhcp6 wm0", where wm0 is the LAN interface.

In a previous discussion, roy@ agreed to check how /etc/resolv.conf
had been created by looking for a "# Generated by resolvconf" line
and only modifying it from resolvconf if that signature was present.

This seems to work most of the time.

Post by Greg Troxel
Also, I really don't understand what you are doing. Are you talking
about running dhcpcd on client machines on the local LAN, or on the
machine that serves the LAN and has an ISP interface too, or semothing
else?

Running it on a client machine on the LAN.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Martin Husemann

2021-10-27 14:24:57 UTC

Permalink

Post by Robert Swindells
I'm telling it via the command line supplied from /etc/rc.conf
with dhcpcd_flags="-6 --nodhcp6 wm0", where wm0 is the LAN interface.

I have a very similar setup on many diskless clients (where the kernel
gets the IPv4 address for booting already and dhcpcd is only used to
setup IPv6 routing later). I use:

ip6mode=autohost
dhcpcd=YES dhcpcd_flags="-6"
nfs_client=YES

and this seems to work (and not overwrite /etc/resolv.conf). I have no
DHCPv6 server on the network, so no need to disable that explicitly for
the client.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Jonathan A. Kollasch

2021-10-27 13:36:12 UTC

Permalink

The current recommended practice is to use a vether(4) for the L3
addresses on the bridge(4), IIUC.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Mouse

2021-10-27 13:43:45 UTC

Permalink

Post by Robert Swindells
I just use dhcpcd(8) to handle IPv6 and use static IPv4 addressing on
my local network with a hand-written /etc/resolv.conf.
If I add the upstream network interface to a bridge(4) then the
/etc/resolv.conf file is overwritten with an empty one, this
obviously breaks DNS lookup on that machine.
Any opinions on whether the current behaviour is sensible and the
best place to fix it if it isn't?

I'm not sure what I think of that.

For some DHCP clients, rewriting /etc/resolv.conf is the Right Thing.
(A roving laptop might be an example.) For others, it's not. (Yours
is an example.)

I'm not sure how to tell the difference mechanically. I'm not even
sure it'd be good to try to tell the difference mechanically;
predictable dumb behaviour is often better than less-predictable
"smart" behaviour.

I could argue either way on which default is better. (In favour of the
current default, I'd guess the correlation between being competent to
notice/fix the issue and being a site for which rewriting is wrong is
positive; against, I'd say that destroying manually configured
information is a Bad Thing - the .save file helps, but it is way too
easy for it to get overwritten, even assuming the admin is aware it
exists.)

As for how to fix it, I put something like this in
/etc/dhclient-enter-hooks on the few of my machines where I actually
use dhclient (this is from one example, I'm not sure they're all
identical, though they're all similar):

#! /bin/sh
RESOLV=/etc/resolv.conf.dhclient
hostname() {
}
domainname() {
}

The RESOLV= line causes the scripts to write a different file, one
which most (all?) automated procedures ignore; the hostname() and
domainname() functions shut off attempts to scribble on the system's
configured names. I could have added overrider functions for
make_resolv_conf() and replace_resolv_conf() instead, but this way I
have the resolv.conf that dhclient would have put in place at ready
hand in case I want something from it.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de