Re: IPv6 on NetBSD 8
Greg Troxel writes: > * drop ip6mode=autohost from rc.conf, so that the default of host > applies. On any interface you want a v6 automatic address, run > dhcpcd. This should just work and you should have useful logs in > /var/log/messages if not. > > So basically those last 4 lines are the migration guide. I should add: * In my experience, dhcpcd doing v6 autoconfiguration just works correctly, with no trouble. * I have a machine configured - with a static v6 address in ifconfig.ucmsc0 (just that one line) - with dhcpcd=YES in rc.conf - with a DHCP-assigned static address (handed out by DHCP server, received by dhcpcd)) - with IPv6 autoconfiguration (because I didn't turn it off in dhcpcd) and this results in the interface having: - static v4 (from /etc/dhcpd.conf on my router matched from mac addr), set by dhcpcd - static v6, setfrom ifconfig.ucmsc0 - stateless privacy v6, set by dhcpcd - IPv6 default route to my router (which is running rtadvd), set by dhcpcd and everything works just fine. The only problem I have had, not about dhcpcd, is if you are trying to use bridge(4) to join two ethernets. Then clients on the secondary one (that rtadvd isn't running on) will end up with the LL addr of the first one as their route, and ND doesn't work right on the bridge looking for the mac addr of the LL addr of the other ethernet. I haven't figured this out, and fudge it with an explicit default route to the LL addr on the secondary ethernet for a machine or two that use that port. My real solution is that I am going to just get a switch and not use bridge(4).
Re: IPv6 on NetBSD 8
On Mon, Jan 28, 2019 at 5:23 PM Jan Danielsson wrote: > > Hello, > >I have a vague memory of having read that IPv6 autoconfiguration has > changed in NetBSD 8. Something along the line of "rtadvd is dead, now > dhcpcd is the way to go". Am I remembering correctly? If so; has > anyone written a migration guide? I'm trying to become well educated on IPv6 but I'm learning new stuff all the time. Probably a lot of people are. dhcpcd is now the standard, and the dhcpcd.conf man page states this: ipv6Enable IPv6 on the interface, on by default. ipv6ra_autoconf Generate SLAAC addresses for each Prefix advertised by an IPv6 Router Advertisement message with the Auto flag set. On by default. http://netbsd.gw.com/cgi-bin/man-cgi?dhcpcd.conf++NetBSD-current So if you're doing something more fancy than just taking a router advertisement and auto configuring an address, you'll probably have to read that and figure it out. It seems pretty well functioned for IPv6 from how I read it. I really need to do more IPv6 testing on NetBSD Andy
Re: IPv6 on NetBSD 8
Jan Danielsson writes: >I have a vague memory of having read that IPv6 autoconfiguration has > changed in NetBSD 8. Something along the line of "rtadvd is dead, now > dhcpcd is the way to go". Am I remembering correctly? If so; has > anyone written a migration guide? What you said isn't right - rtadvd is the router part. As I understand things: * running rtadvd (or using quagga) on the router, to *advertise* a prefix and default router, remains the standard approach * In NetBSD < 8, for a very long time, stateless autoconfiguration was done by setting ip6mode=autohost in rc.conf, and that set net.inet6.ip6.accept_rtadv = 1 which caused the kernel to process Router Advertisements and create v6 addresses using stateless autoconfiguration, when such RAs arrived. In addition, one could run rtsol (once) to send a solicitation, or rtsold to send them periodically. * dhcpcd does IPv6 stateless autoconfiguration (with privacy extensions) by default (well, with the default config file at least). This is essentially the same mechanism as the kernel RA listener and rtsold, but as I understand it with more care about correctness (and less use of kernel code). Plus, it implements the privacy extensions, which allow stable addresses which cannot be matched to MAC addresses. I think in NetBSD 8 you have two options: * leave ip6mode=autohost in your rc.conf. The in-kernel listener will run. No Router Solicitations will be sent. It's unclear what happens if you do this and run dhcpcd at the same time. I do not recommend this. * drop ip6mode=autohost from rc.conf, so that the default of host applies. On any interface you want a v6 automatic address, run dhcpcd. This should just work and you should have useful logs in /var/log/messages if not. So basically those last 4 lines are the migration guide.
IPv6 on NetBSD 8
Hello, I have a vague memory of having read that IPv6 autoconfiguration has changed in NetBSD 8. Something along the line of "rtadvd is dead, now dhcpcd is the way to go". Am I remembering correctly? If so; has anyone written a migration guide? -- Kind Regards, Jan
Re: Clock Unsynchronized
I remember having problems sometimes ago when my NetBSD machines were around 8.99.25 or so (my timeserver is an RPI Model B still on 8.99.2). I haven't had these problems for a while, but all my -current machines are on 8.99.32. Chavdar On Mon, 28 Jan 2019 at 15:51, Patrick Welche wrote: > > Just noticed (NetBSD-8.99.26/amd64): > > ntpd[1575]: kernel reports TIME_ERROR: 0x4041: Clock Unsynchronized > > This is after a ntpdate which succeeded in catching up the 3/4 hour > that clock was behind by. I haven't seen this error before... > > Is ACPI-Fast a good choice? (I didn't choose...) > > # sysctl kern.timecounter > kern.timecounter.choice = TSC(q=-100, f=2666902400 Hz) clockinterrupt(q=0, > f=100 Hz) ichlpcib0(q=1000, f=3579545 Hz) ACPI-Fast(q=1000, f=3579545 Hz) > lapic(q=-100, f=266767233 Hz) i8254(q=100, f=1193182 Hz) dummy(q=-100, > f=100 Hz) > kern.timecounter.hardware = ACPI-Fast > kern.timecounter.timestepwarnings = 0 > > > Cheers, > > Patrick --
NetBSD 8.0 EC2 AMIs
Hello, https://wiki.netbsd.org/amazon_ec2/amis/ currently lists NetBSD 7.0 as the latest version for which there are AWS EC2 AMIs available. Is that correct, or are there any official NetBSD 8.0 images available? -Jan
Clock Unsynchronized
Just noticed (NetBSD-8.99.26/amd64): ntpd[1575]: kernel reports TIME_ERROR: 0x4041: Clock Unsynchronized This is after a ntpdate which succeeded in catching up the 3/4 hour that clock was behind by. I haven't seen this error before... Is ACPI-Fast a good choice? (I didn't choose...) # sysctl kern.timecounter kern.timecounter.choice = TSC(q=-100, f=2666902400 Hz) clockinterrupt(q=0, f=100 Hz) ichlpcib0(q=1000, f=3579545 Hz) ACPI-Fast(q=1000, f=3579545 Hz) lapic(q=-100, f=266767233 Hz) i8254(q=100, f=1193182 Hz) dummy(q=-100, f=100 Hz) kern.timecounter.hardware = ACPI-Fast kern.timecounter.timestepwarnings = 0 Cheers, Patrick
