dhcpcd-discuss

It's more than annoying because I had to also clean up the route table
with ip instead of route because of the fine grain control which come
with it. All the bridge i.e switches and tap devices i.e interfaces
attached to virtual switch and virtual machine had to be handled: one,
to reset the 169.254.0.0/16 addresse; two, to clear up the route
associated route wich is displayed like the following.

% ip route show
[...]
169.254.0.0/16 dev vnet1  proto kernel  scope link  src 169.254.246.221 metric 222
169.254.0.0/16 dev vnet4_0  proto kernel  scope link  src 169.254.221.89 metric 213
[...]

or

% route # on a Linux box
[...]
link-local      0.0.0.0         255.255.0.0     U     212    0        0 vnet4
link-local      0.0.0.0         255.255.0.0     U     213    0        0 vnet4_0
[...]

I did not find a command to delete those route with `route' but on with
`ip':
for j in $RANGE1; do
  for i in $RANGE2; do
    ip route del scope link 169.254.0.0/16 dev vnet${j}_$i;
  done;
done

I's more annoying than you think when there a networok event wich
trigger new address assignment which in turn havoc the whole virtual
LANs and then flood the system logger with blocked and rejected
connections.

DHClient is also annoying with try to get address to interface which
have already address--something dhcpcd would not try and block
interfaces for no good reasons.

I guess the only solution is set up everything as static address as
possible to avoid using any DHCP client. What's?! Well, I cannot do that
for the moment.

On Sun, Oct 09, 2016 at 11:05:22AM +0200, tokiclover wrote:

> Date: Sun, 9 Oct 2016 11:03:42 +0200
> From: tokiclover <tokiclover@xxxxxxxxx>
> Subject: Re: [dhcpcd-discuss] dhcpcd-6.11.5 released
> To: Roy Marples <roy@xxxxxxxxxxxx>
> 
> It looks like --denyinterfaces works as expected without jeopardizing
> the interfaces as previously reported. Without it, I have to resort to a
> for loop to set 0.0.0.0 to interfaces. And doing this does not crash
> dhcpcd as previously reported for dhcpcd-6.11.3.
> 
> Thanks!