odhcp6c
odhcp6c copied to clipboard
prefix lifetimes on comcast
OK, so I finally got odhcp6c up and running on debian, where life is easier to debug, and after flailing mightily against dibbler, dhclient, and wide.
Tearing apart the script, I see
RA_ROUTES=::/0,fe80::22e5:2aff:feb8:14f,1769,512 2601:646:8301:c500::/64,,345569,256 2601:646:8301:c500::/56,fe80::22e5:2aff:feb8:14f,345569,512
PREFIXES=2601:646:8301:c5f0::/60,30,60
And indeed, I see it requesting a renew (preferred lifetime of 0) every 10 seconds or so, and getting back the renew for preferred/valid 30/60 seconds....
I can't remember where we left off on this before.
relevant cap: http://snapon.lab.bufferbloat.net/~d/comcast.dhcpv6/dhcp.cap
root@ranger:/tmp# ip -6 addr show eth2 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2601:646:8301:c500:225:90ff:fef4:a5c4/64 scope global dynamic valid_lft 344680sec preferred_lft 344680sec inet6 2601:646:8301:c500::1/128 scope global dynamic valid_lft 57sec preferred_lft 27sec
I stuck a couple logfiles in the above dir also.
sigh: - also flushing all on the interface makes for bad behavior.
Jun 18 17:22:08 ranger ntpd[1335]: Deleting interface #637 eth2, 2601:646:8301:c500::1#123, interface stats: received=0, sent=0, dropped=1, active_time=854 secs Jun 18 17:22:08 ranger ntpd[1335]: peers refreshed un 18 17:22:23 ranger avahi-daemon[554]: Registering new address record for 2601:646:8301:c500::1 on eth2.*. Jun 18 17:22:26 ranger ntpd[1335]: Listen normally on 640 eth2 2601:646:8301:c500::1 UDP 123 Jun 18 17:22:26 ranger ntpd[1335]: 2600:3c00::f03c:91ff:fe96:a6 interface 2601:646:8301:c500:225:90ff:fef4:a5c4 -> 2601:646:8301:c500::1 Jun 18 17:22:26 ranger ntpd[1335]: peers refreshed Jun 18 17:22:26 ranger ntpd[1335]: new interface(s) found: waking up resolver Jun 18 17:22:36 ranger dhcpd: DHCPDISCOVER from 00:25:90:f6:b5:b6 via Jun 18 17:22:51 ranger avahi-daemon[554]: Withdrawing address record for 2601:646:8301:c500::1 on eth2. Jun 18 17:23:23 ranger ntpd[1335]: Deleting interface #640 eth2, 2601:646:8301:c500::1#123, interface stats: received=1, sent=1, dropped=0, active_time=57 secs Jun 18 17:23:23 ranger ntpd[1335]: 2600:3c00::f03c:91ff:fe96:a6 interface 2601:646:8301:c500::1 -> (none) Jun 18 17:23:23 ranger ntpd[1335]: peers refreshed
Jun 18 17:23:37 ranger kernel: [166971.050031] IPv6: eth2: IPv6 duplicate address 2601:646:8301:c500::1 detected! Jun 18 17:23:53 ranger avahi-daemon[554]: Registering new address record for 2601:646:8301:c500::1 on eth2.*. Jun 18 17:23:55 ranger ntpd[1335]: Listen normally on 641 eth2 2601:646:8301:c500::1 UDP 123 Jun 18 17:23:55 ranger ntpd[1335]: 2600:3c00::f03c:91ff:fe96:a6 interface 2601:646:8301:c500:225:90ff:fef4:a5c4 -> 2601:646:8301:c500::1 Jun 18 17:23:55 ranger ntpd[1335]: peers refreshed Jun 18 17:23:55 ranger ntpd[1335]: new interface(s) found: waking up resolver
In terms of being kinder and gentler I modified the example script somewhat:
https://github.com/sbyx/odhcp6c/compare/master...dtaht:master
I got to where my connection was not flapping like crazy anymore with the current stuff in my fork. However I am still working out details here and in #36
still, what does it take to get a prefix lifetime longer than 60 seconds?
I guess the current example script is a bit harsh in flushing addresses and routes, however to do that better I would probably need to export more state (i.e. also addresses prefixes that got deleted not only those present or well make the handler-script store them in a /tmp-file).
Anyway, the lifetimes of addresses and prefixes are determined by the server, not much you can do about that probably.
Well, losing connectivity for 2 seconds out of every 60 is not a goodness. Nor is resetting ntp, mdns, and other services.
And all I do is just let the addresses expire if I dont get them back. No state required.