Skip to content
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

Open
dtaht opened this issue Jun 18, 2015 · 8 comments
Open

prefix lifetimes on comcast #35

dtaht opened this issue Jun 18, 2015 · 8 comments

Comments

@dtaht
Copy link

dtaht commented Jun 18, 2015

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
Copy link
Author

dtaht commented Jun 18, 2015

@dtaht
Copy link
Author

dtaht commented Jun 19, 2015

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
Copy link
Author

dtaht commented Jun 19, 2015

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
Copy link
Author

dtaht commented Jun 19, 2015

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

sbyx/odhcp6c@master...dtaht:master

@dtaht
Copy link
Author

dtaht commented Jun 19, 2015

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
Copy link
Author

dtaht commented Jun 19, 2015

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

@sbyx
Copy link
Member

sbyx commented Jun 19, 2015

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
Copy link
Author

dtaht commented Jun 25, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants