prefix lifetimes on comcast

[dtaht]

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]

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

[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]

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]

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

sbyx/odhcp6c@master...dtaht:master

[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]

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

[sbyx]

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.

[dtaht]

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.

[l-jonas]

I consider the bundled example script not a good one, but an example. In combination with netifd, this issue does most likely not occur.

As this issue is ten years old, I assume it's kind of obsolete.