odhcp6c icon indicating copy to clipboard operation
odhcp6c copied to clipboard

prefix lifetimes on comcast

Open dtaht opened this issue 9 years ago • 8 comments

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.

dtaht avatar Jun 18 '15 23:06 dtaht

relevant cap: http://snapon.lab.bufferbloat.net/~d/comcast.dhcpv6/dhcp.cap

dtaht avatar Jun 18 '15 23:06 dtaht

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.

dtaht avatar Jun 19 '15 00:06 dtaht

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

dtaht avatar Jun 19 '15 00:06 dtaht

In terms of being kinder and gentler I modified the example script somewhat:

https://github.com/sbyx/odhcp6c/compare/master...dtaht:master

dtaht avatar Jun 19 '15 02:06 dtaht

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

dtaht avatar Jun 19 '15 19:06 dtaht

still, what does it take to get a prefix lifetime longer than 60 seconds?

dtaht avatar Jun 19 '15 19:06 dtaht

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.

sbyx avatar Jun 19 '15 19:06 sbyx

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.

dtaht avatar Jun 25 '15 02:06 dtaht