Hi,
I'm experiencing a problem with my NetBSD AWS EC2
instance flapping the default IPv6 route:
The system is an amd64 EC2 instance using:
# uname -a
NetBSD netbsd 9.99.78 NetBSD 9.99.78 (GENERIC) #0: Fri Jan 22 00:44:55 UTC 2021
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
Greg Troxel wrote:
>
> Jan Schaumann writes:
>
> > Apr 20 01:32:32 netbsd dhcpcd[17397]: xennet0: soliciting an IPv6 router
> > Apr 20 01:32:34 netbsd dhcpcd[17397]: xennet0: Router Advertisement from
> > fe80::caa:49ff:feaf:1815
> > Apr 20 01:32:35 netbsd
Martin Husemann wrote:
> Well, adding -v or -vv would help here, especially to show the RA lifetime.
RA lifetime is 1800s:
IP6 (hlim 255, next-header ICMPv6 (58) payload length: 56) fe80::caa:49ff:feaf:1
815 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 56
hop limit 255,
Greg Troxel wrote:
> Besides -v, tcpdump prints timestamps and those were omitted. Also the
> lines were miswrapped making them very hard to read.
You can grab a pcap file from here:
https://www.netmeister.org/tmp/ipv6.pcap
That's "tcpdump -w ipv6.pcap ip6" while running "ping6
www.yahoo.com"
Robert Elz wrote:
> It seems as if what is happening, is that the router is sending RA's with
> the source-link addr option, which isn't being added to the neighbour
> cache.
Yes, it looks like that's what's going on here.
It seems that:
A RS is sent by the node.
The router replies with a RA
Jan Schaumann wrote:
> Btw, if you want to replicate the setup and have an
> AWS account, you can use ami-0018b2d98332ba7e3 (in
> us-east-1), which is the AMI I'm using here.
Oh, and if anybody here wants to access the actual
system, send me an ssh pubkey, and I can add you to an
Jan Schaumann wrote:
> So if this is correct, then it looks like (a) the
> router is misbehaving (it should send a NA when we so
> politely ask)
Joerg found the culprit:
It turns out that apparently the router will only
reply with NAs to a NS that originates from a
predicted IPv
NetBSD Test Fixture wrote:
> This is an automatically generated notice of a new failure of the
> NetBSD test suite.
>
> The newly failing test case is:
>
> lib/libc/net/t_protoent:protoent
>
> The above test failed in each of the last 4 test runs, and passed in
> at least 26 consecutive run
Hello,
I just spent some time shaving the /etc/protocols
generation yak. As best as I can tell the process how
that file is maintained is not documented and consists
of:
1) building the pkgsrc/net/iana-etc package
This package pulls a few scripts from
http://sethwklein.net/iana-etc, which hasn'
Christos Zoulas wrote:
> Sounds good to me, perhaps something like
> src/etc/refresh-data/ with some structure under
> there?
I have a few scripts here:
https://www.netmeister.org/tmp/iana-data.tar.gz
Two questions:
1) Since this is solving the same problem using the
same input and producing th
Hello,
OpenSSL 1.1.1 will reach EOL on September 11th, 2023,
less than 5 months from today:
https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
What's NetBSD's plan going forward - update to 3.x?
-Jan
Jan Schaumann wrote:
> OpenSSL 1.1.1 will reach EOL on September 11th, 2023,
> less than 5 months from today:
>
> https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
>
> What's NetBSD's plan going forward - update to 3.x?
Following up here for the archive
[ +current-users@ with full-quote for context ]
> It looks like in order to be able to use sys/clock.h,
> one needs to first include either inttypes.h or
> stdint.h _before_ sys/clock.h.
>
> I've long made it a habit of sorting includes
> alphabetically and according to /usr/share/misc/style,
> w
Simon Burge wrote:
> +#if !defined(_KERNEL) && !defined(_STANDALONE)
> +#include
> +#endif
>
> Sorry for chiming in late. Wouldn't it be better to include
> and avoid the #ifdef? Especially since
> is a symlink to .
That makes sense to me - made it so. :-)
Thanks!
-Jan
Tobias Nygren wrote:
> The header being used from the tools build was an unexpected surprise
> but such reasons are why those ifdef guards exist. So I think it
> just just be put back the way it was. The example came from
> sys/atomic.h so it shouldn't be controversial.
I've just reverted the la
Hi,
The sockaddr_un.sun_path length is currently fixed at
104 characters in NetBSD (as well as FreeBSD and
macOS, at least). FreeBSD uses a 'define' for this
value, together with an explanatory comment, which I
find rather useful:
/*
* Historically, (struct sockaddr) needed to fit
* inside an
NetBSD Test Fixture wrote:
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on babylon4.netbsd.org, a NetBSD/amd64 host,
> using sources from CVS date 2024.11.09.15.56.35.
Whoops, my fault. Fixed.
-Jan
"Greg A. Woods" wrote:
> At Thu, 27 Feb 2025 17:49:15 -0500, Jan Schaumann
> wrote:
> Subject: Re: running NetBSD under UTM (with QEMU) on macOS
> >
> > I've been using NetBSD on UTM since
> > NetBSD-current-before-10.0 (now
"Greg A. Woods" wrote:
> I set up a test VM with UTM sometime last year, but the networking
> seemed a little unstable. I'm not sure that's resolved yet. It seems
> like it might be a macOS problem with the underlying bridge disappearing
> or changing. The VM still thinks the interface is up,
19 matches
Mail list logo
