RE: IPV4LL and EXPIRE
Roy Marples
Fri Oct 17 23:54:23 2014
Hi David
On 2014-10-18 00:02, David Hauck wrote:
I wonder if some of this behaviour is a consequence of running in a
multi-homed environment (note my use of testing this 'eth1'). I have
an initial interface that's defined statically and after taking a
quick look at the code I'm wondering whether there's some mixup
related to detecting valid IPV4LL addresses (both after CARRIER and
EXPIRE)? For example, the node's ARP table includes *all* the IPV4LL
addresses ever issued during the uptime of the node:
I normally run on mutli-homed systems myself.
Infact, a new feature in dhcpcd-6.5.1 is the ability to share a leased
IP across interfaces. The idea being that you get the same IP for both
wired and wireless so it doesn't matter which is plugged in, you can
connect to it remotely fine!
Nothing todo with IPv4LL, but worth mentioning.
Address HWtype HWaddress Flags Mask
Iface
169.254.6.164 ether 00:0b:ab:36:1c:fc C
eth0
169.254.137.181 ether 00:0b:ab:36:1c:fc C
eth0
169.254.85.96 ether 00:0b:ab:36:1c:fc C
eth0
169.254.239.209 ether 00:0b:ab:36:1c:fc C
eth0
169.254.141.93 ether 00:0b:ab:36:1c:fc C
eth0
169.254.102.255 ether 00:0b:ab:36:1c:fc C
eth0
169.254.91.215 ether 00:0b:ab:36:1c:fc C
eth0
169.254.213.163 ether 00:0b:ab:36:1c:fc C
eth0
169.254.213.103 ether 00:0b:ab:36:1c:fc C
eth0
169.254.178.40 ether 00:0b:ab:36:1c:fc C
eth0
169.254.158.92 ether 00:0b:ab:36:1c:fc C
eth0
169.254.250.88 ether 00:0b:ab:36:1c:fc C
eth0
169.254.179.113 ether 00:0b:ab:36:1c:fc C
eth0
169.254.242.1 ether 00:0b:ab:36:1c:fc C
eth0
169.254.200.24 ether 00:0b:ab:36:1c:fc C
eth0
169.254.137.153 ether 00:0b:ab:36:1c:fc C
eth0
169.254.12.151 ether 00:0b:ab:36:1c:fc C
eth0
169.254.99.154 ether 00:0b:ab:36:1c:fc C
eth0
169.254.156.90 ether 00:0b:ab:36:1c:fc C
eth0
169.254.197.37 ether 00:0b:ab:36:1c:fc C
eth0
169.254.141.211 ether 00:0b:ab:36:1c:fc C
eth0
169.254.118.176 ether 00:0b:ab:36:1c:fc C
eth0
169.254.40.191 ether 00:0b:ab:36:1c:fc C
eth0
dhdell.nacc.netacquire. ether 18:03:73:e2:3e:c7 C
eth0
169.254.252.49 ether 00:0b:ab:36:1c:fc C
eth0
169.254.213.135 ether 00:0b:ab:36:1c:fc C
eth0
169.254.141.75 ether 00:0b:ab:36:1c:fc C
eth0
169.254.224.247 ether 00:0b:ab:36:1c:fc C
eth0
169.254.159.116 ether 00:0b:ab:36:1c:fc C
eth0
169.254.103.7 ether 00:0b:ab:36:1c:fc C
eth0
169.254.100.217 ether 00:0b:ab:36:1c:fc C
eth0
169.254.218.127 ether 00:0b:ab:36:1c:fc C
eth0
169.254.7.207 ether 00:0b:ab:36:1c:fc C
eth0
169.254.223.197 ether 00:0b:ab:36:1c:fc C
eth0
169.254.246.74 ether 00:0b:ab:36:1c:fc C
eth0
169.254.127.124 ether 00:0b:ab:36:1c:fc C
eth0
169.254.98.75 ether 00:0b:ab:36:1c:fc C
eth0
169.254.210.143 ether 00:0b:ab:36:1c:fc C
eth0
169.254.24.54 ether 00:0b:ab:36:1c:fc C
eth0
169.254.184.234 ether 00:0b:ab:36:1c:fc C
eth0
169.254.140.128 ether 00:0b:ab:36:1c:fc C
eth0
naccserver1.nacc.netacq ether b8:ac:6f:97:55:be C
eth0
test ether 00:0b:ab:36:1c:fc C
eth0
169.254.252.47 ether 00:0b:ab:36:1c:fc C
eth0
169.254.46.54 ether 00:0b:ab:36:1c:fc C
eth0
169.254.173.190 ether 00:0b:ab:36:1c:fc C
eth0
169.254.30.240 ether 00:0b:ab:36:1c:fc C
eth0
169.254.95.73 ether 00:0b:ab:36:1c:fc C
eth0
205.159.216.130 ether 74:44:01:d5:26:06 C
eth0
169.254.129.156 ether 00:0b:ab:36:1c:fc C
eth0
169.254.25.129 ether 00:0b:ab:36:1c:fc C
eth0
169.254.52.241 ether 00:0b:ab:36:1c:fc C
eth0
169.254.42.114 ether 00:0b:ab:36:1c:fc C
eth0
169.254.91.128 ether 00:0b:ab:36:1c:fc C
eth0
169.254.155.165 ether 00:0b:ab:36:1c:fc C
eth0
169.254.196.42 ether 00:0b:ab:36:1c:fc C
eth0
169.254.129.140 ether 00:0b:ab:36:1c:fc C
eth0
169.254.84.9 ether 00:0b:ab:36:1c:fc C
eth0
169.254.23.202 ether 00:0b:ab:36:1c:fc C
eth0
169.254.124.132 ether 00:0b:ab:36:1c:fc C
eth0
169.254.14.64 ether 00:0b:ab:36:1c:fc C
eth0
169.254.131.4 ether 00:0b:ab:36:1c:fc C
eth0
169.254.31.191 ether 00:0b:ab:36:1c:fc C
eth0
169.254.142.131 ether 00:0b:ab:36:1c:fc C
eth0
169.254.189.82 ether 00:0b:ab:36:1c:fc C
eth0
169.254.85.169 ether 00:0b:ab:36:1c:fc C
eth0
169.254.29.133 ether 00:0b:ab:36:1c:fc C
eth0
169.254.115.246 ether 00:0b:ab:36:1c:fc C
eth0
169.254.218.133 ether 00:0b:ab:36:1c:fc C
eth0
169.254.253.103 ether 00:0b:ab:36:1c:fc C
eth0
169.254.182.140 ether 00:0b:ab:36:1c:fc C
eth0
169.254.39.105 ether 00:0b:ab:36:1c:fc C
eth0
169.254.170.69 ether 00:0b:ab:36:1c:fc C
eth0
169.254.17.98 ether 00:0b:ab:36:1c:fc C
eth0
169.254.183.77 ether 00:0b:ab:36:1c:fc C
eth0
169.254.23.60 ether 00:0b:ab:36:1c:fc C
eth0
169.254.32.3 ether 00:0b:ab:36:1c:fc C
eth0
169.254.93.109 ether 00:0b:ab:36:1c:fc C
eth0
169.254.198.140 ether 00:0b:ab:36:1c:fc C
eth0
169.254.17.77 ether 00:0b:ab:36:1c:fc C
eth0
169.254.219.46 ether 00:0b:ab:36:1c:fc C
eth0
169.254.248.78 ether 00:0b:ab:36:1c:fc C
eth0
169.254.50.206 ether 00:0b:ab:36:1c:fc C
eth0
169.254.188.25 ether 00:0b:ab:36:1c:fc C
eth0
169.254.40.30 ether 00:0b:ab:36:1c:fc C
eth0
169.254.80.209 ether 00:0b:ab:36:1c:fc C
eth0
169.254.82.89 ether 00:0b:ab:36:1c:fc C
eth0
205.159.216.145 ether 90:b1:1c:5e:80:bb C
eth0
169.254.37.180 ether 00:0b:ab:36:1c:fc C
eth0
169.254.63.138 ether 00:0b:ab:36:1c:fc C
eth0
169.254.35.255 ether 00:0b:ab:36:1c:fc C
eth0
169.254.236.137 ether 00:0b:ab:36:1c:fc C
eth0
169.254.5.171 ether 00:0b:ab:36:1c:fc C
eth0
naccserver1.nacc.netacq ether b8:ac:6f:97:55:be C
eth1
169.254.44.140 ether 00:0b:ab:36:1c:fc C
eth0
169.254.129.88 ether 00:0b:ab:36:1c:fc C
eth0
169.254.23.183 ether 00:0b:ab:36:1c:fc C
eth0
169.254.82.160 ether 00:0b:ab:36:1c:fc C
eth0
169.254.141.66 ether 00:0b:ab:36:1c:fc C
eth0
169.254.99.210 ether 00:0b:ab:36:1c:fc C
eth0
169.254.214.134 ether 00:0b:ab:36:1c:fc C
eth0
169.254.93.134 ether 00:0b:ab:36:1c:fc C
eth0
169.254.143.66 ether 00:0b:ab:36:1c:fc C
eth0
169.254.49.147 ether 00:0b:ab:36:1c:fc C
eth0
169.254.202.127 ether 00:0b:ab:36:1c:fc C
eth0
169.254.116.117 ether 00:0b:ab:36:1c:fc C
eth0
169.254.84.240 ether 00:0b:ab:36:1c:fc C
eth0
So the uniqueness test is likely failing.
I would disagree. We have 254x254 addresses to play with, this list is
short. There should be minimal conflict.
Still, emptying the ARP table wouldn't be all bad, removes an unknown
variable.
But this is only because the
previous IPV4LL address (prior to losing CARRIER) is somehow being
re-used after CARRIER is re-established. So there may be two problems
here: 1) for some reason not proceeding to a normal DHCP exchange
after an IPV4LL state loses CARRIER and then regains CARRIER, and 2)
IPV4LL collisions on a multi-homed configuration?
We just saw 1), something expired and didn't attempt DHCP.
Hard to say for sure without the debug flag in dhcpcd.conf - please add
it!
Anyways, just forwarding along additional information. There's no rush
to respond on any of this - we can pick things up at your leisure next
week.
I'm away for the weekend now pretty much so next week is fine.
Roy
Archive administrator: postmaster@marples.name