- User Since
- Aug 2 2016, 5:23 PM (159 w, 5 d)
Feb 28 2019
Hmmm. I'll try to help you debug this issue offline (look for my message).
I've reproduced the hang you described on a test router. It looks like this:
Hmmm. My next guess would be that you could be inadvertently blocking neighbor discovery (which happens on the link-local addresses). Can you try turning off the IPv6 firewall long enough to test whether it's the firewall at all? Another thing to try would be tcpdump on the LAN and WAN interfaces, as well as putting another machine (like a laptop) on the link between the two routers, to see where the packets are appearing and not appearing. You should see lots of link-local traffic between the LAN hosts and the VyOS router, as well as between the two routers.
Feb 27 2019
Ah, interesting. I'll see if I can reproduce the address dhcpv6 problem.
Feb 26 2019
Yeah, I still have a bit of debug output in there. Easy enough to remove.
Great! The one I built last night is still available here: http://www.avernus.com/~gadams/vyos-crux.201902250834.dhcpv6pd-amd64.iso
Indeed, this is on Comcast Business. At least they're consistent in their oddity, eh?
Great! I'll look forward to hearing how it works for you.
Feb 25 2019
I've learned a lot about building ISO images over the past couple weeks. I have a first version of my change ready; it's in two commits currently:
I'm a little confused about the status of this task.
Feb 17 2019
Oy. Turns out that other routers (like those that found in ISP-provided cable modems) can have subtle quirks in their DHCPv6-PD implementations. I've worked around another one.
Feb 13 2019
A quick progress update: I have fixed a bug (that may or may not have been present before) that prevented renew dhcpv6 interface eth3 (or whatever interface) from working outside of an active configuration session. I imagine most uses of dhcp lease renewal would occur in a normal router login session.
Feb 10 2019
Well, I've been developing it against the 1.2.0 branch. It might work back-ported to 1.1.8, but that's not my focus.
Hey! Sorry I was out for a bit. But I'm back now. Time to catch up.
Dec 3 2018
@aaliddell No worries! It was a really easy fix. :)
Nov 29 2018
Did there turn out to a be problem with this fix? I definitely need it in my environment, where I run dhclient on eth3 or br0, and eth0 never gets an IPv6 address (link local or otherwise).
Nov 28 2018
I have now implemented the syntax I described above. There are still some edge cases, mostly because of the fact that dhclient is started in a whole bunch of places, and making it all consistent is tricky. Perhaps refactoring /opt/vyatta/sbin/vyatta-dhcpv6-client.pl (probably rewriting it in Python) is in order. I may not do that right now, though.
OK! I'm happy to say that I have prefix delegation working with ISC dhclient, now, using a dhclient exit hook to collect the delegated prefix and farm out chunks of it to local interfaces. Now I'm tnhinking about the configuration syntax.
Nov 27 2018
Hey, laziness is a programmer virtue, remember!
Aha! Looking into it a bit more, the hook scripts are given the environment variables new_ip6_prefix and old_ip6_prefix, so that's where we should get the delegated prefix (and remove an old one, as appropriate). So, all we need to do is add some configuration settings to request PD and to indicate a subnet number within the delegated prefix to assign out to any desired interfaces. Then, it's a simple matter of exit-hook scripting to set this all up.
Nov 26 2018
That's very interesting. Thanks for sharing.
Nov 8 2018
I have sent a pull request that adds support for outbound IPv6 queries, implementing what I described above: https://github.com/vyos/vyos-1x/pull/58.
Yes, that change works. I'll look forward to it appearing in an RC. :)
Aha! I have figured out what causes pdns-recursor not to answer requests on its IPv6 sockets, even though it binds to them. It's the allow-from setting. If I change it from:
then everything works.
Nov 7 2018
The plot thickens, however. According to netstat -an | grep :53, it is listening on the IPv6 addresses specified.
Yes, I concur that keeping just listen-address for both address types would definitely be preferable, and we should just distinguish between them when building the config, if needed.
Oct 17 2018
A long time ago (before Oct 2016) I built Roy Marples' dhcpcd and hacked
/opt/vyatta/etc/config/scripts/vyatta-postconfig-bootup.script to install, configure, and start it up. I've been running with this config for over two years, and it's pretty stable. I'd love for this to be built into VyOS, rather than a local config hack.
Oct 29 2016
Hmm. Things are afoot.
Oct 7 2016
Recent dev builds on the current (lithium) branch don't need to be told which port is the console; systemd is able to figure it out, and spawns the correct getty processes.
Oct 6 2016
I've written a handy script to start ntpd manually:
I tried adding this to /config/scripts/vyatta-postconfig-bootup.script:
This hack does work, but it only lasts until you reboot VyOS. When the OS comes back up, you'll need to do this again.
Sep 21 2016
I have sent a pull request.
Sep 16 2016
Sep 8 2016
Most likely postinst, but I can't find that file in the git repos.
Aha!. I've tried 999.201609070235 (current). Things look quite a bit better; /opt/vyatta/etc/config/scripts/vyatta-postconfig-bootup.script is now persisted, and things seem to start up and run quite nicely.
It should be safe to start a getty on ttyS1 (in addition to the one on ttyS0) for all devices, shouldn't it? Even on devices that don't have a ttyS1 (or even a ttyS0), that shouldn't cause any failures.
Aha! I think I have found the cause. In vyatta-boot-image.pl, there is this code:
Ooh. I see that the script that copies over the ssh keys is vyatta-cfg-system/scripts/install/install-image-existing, but it's run on the old system--the one you're upgrading from. So putting the fix in there would require upgrading the old OS first.
Aug 10 2016
Unfortunately, I'm traveling right now, so I'll have to try out a newer image and give you the output from 'sudo blkid' in three weeks. I'll look forward to some good progress when I return!