-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
prefix lifetimes on comcast #35
Comments
root@ranger:/tmp# ip -6 addr show eth2 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:23:37 ranger kernel: [166971.050031] IPv6: eth2: IPv6 duplicate address 2601:646:8301:c500::1 detected! |
In terms of being kinder and gentler I modified the example script somewhat: |
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. |
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.
The text was updated successfully, but these errors were encountered: