[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Assorted arm-buster problems - network configuration



	Hi.

On Sun, Jul 07, 2019 at 09:58:46AM +0300, andreimpopescu@gmail.com wrote:
> On Sb, 06 iul 19, 18:14:04, Gene Heskett wrote:
> > 
> > If you read the full thread, you will find where I found and fixed that 
> > problem, by killing dhcpd5 with htop, and restarting networking, and 
> > the problem was fixed, everything then worked correctly, 
> 
> Did you ever find out why dhcpcd5 was even starting?

I solved this mystery.
Took an upgrade to buster, and somewhat botched network configuration in
the result. But it was worth it.

First, unlike ISC dhclient, which is the 'goto' DHCP client in Debian,
Raspbian promoted dhcpcd5 into this role.

Second, unlike dhclient, dhcpcd5 can work as a systemwide daemon, and if
run like that it tries to get a lease on every network interface if it's
UP and it's not a "lo". This can be changed via dhcpcd.conf, but it's
not done by default.

Third, /etc/init.d/dhcpcd contains a useful safeguard - a single
interface defined as "inet dhcp" in e/n/i prevents systemwide daemon
from running. In full accordance with Debian policy, dhcpcd5 tries to
run such daemon by default.

So far - so good, but buster's dhcpcd added fourth - a systemd unit that
runs /usr/sbin/dhcpcd regardless of a safeguard.
A result, assuming systemd as PID 1 - stretch's dhcpcd respects e/n/i,
buster's - does not. As an added "bonus" - buster's dhcpcd does not
respect "metric" setting in these circumstances.


A fun parts here are:

1) Problem is easily solved with the usual "systemctl disable/systemctl
stop" combo.

2) Debian does not exibit this behaviour by default, user has to install
dhcpcd5 package (which I do, because $REASONS).

3) Raspbian seem to be broken by default in this regard, but … you're
not supposed to edit e/n/i if using Raspbian as far as I understand.
Because you can always get DHCP lease and it's confusing to the user and
all that :)


As an upside, they finally fixed dhcpcd's ntp hook - it was broken in
stretch.

Reco


Reply to: