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 IPv6 address. That
On Wed, 21 Apr 2021, Robert Swindells wrote:
Think we need to make dhcpcd work with rump if it is the only way to
do RA processing.
And create an appropriate set of rump-based atf tests to detect future
regressions.
++--+---+
|
Joerg Sonnenberger wrote:
>On Wed, Apr 21, 2021 at 02:21:51AM -0700, John Nemeth wrote:
>> On Apr 20, 21:13, Joerg Sonnenberger wrote:
>> } On Wed, Apr 21, 2021 at 12:54:36AM +0700, Robert Elz wrote:
>> } > It seems as if what is happening, is that the router is sending RA's with
>> } > the sour
On Wed, Apr 21, 2021 at 02:21:51AM -0700, John Nemeth wrote:
> On Apr 20, 21:13, Joerg Sonnenberger wrote:
> } On Wed, Apr 21, 2021 at 12:54:36AM +0700, 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 b
On Apr 20, 21:13, Joerg Sonnenberger wrote:
} On Wed, Apr 21, 2021 at 12:54:36AM +0700, 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.
} >
} > Then NetBSD is doing
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
instance that e
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
Date:Wed, 21 Apr 2021 03:48:00 +0700
From:Robert Elz
Message-ID: <2704.1618951...@jinx.noi.kre.to>
| | Except of course that it introduces back all the reasons for why it was
| | removed in first place and ignores that it shouldn't happen.
|
| I'm not sur
Date:Tue, 20 Apr 2021 21:13:15 +0200
From:Joerg Sonnenberger
Message-ID:
| I'm not entirely sure that the behavior of sending a RA as "answer" to a
| NS is valid under RFC 4861,
Nor am I, but it appears that is what is happening, and that other clients
don't min
Joerg Sonnenberger writes:
> On Wed, Apr 21, 2021 at 12:54:36AM +0700, 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.
>>
>> Then NetBSD is doing a NS to discover th
On Wed, Apr 21, 2021 at 12:54:36AM +0700, 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.
>
> Then NetBSD is doing a NS to discover the address it ignored from the RA,
> b
Date:Tue, 20 Apr 2021 12:54:57 -0400
From:Jan Schaumann
Message-ID: <20210420165457.ge5...@netmeister.org>
| You can grab a pcap file from here:
| https://www.netmeister.org/tmp/ipv6.pcap
It looks to me as if the problem might be that NetBSD has removed too much
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"
Martin Husemann writes:
> Well, adding -v or -vv would help here, especially to show the RA lifetime.
>
> But more interesting is what happens on the routing socket, as that is
> where dhcpcd gets the idea of reachability from.
A great suggestion and I 'll add turning on dhcpcd debugging and lo
On Tue, Apr 20, 2021 at 10:09:47AM -0400, Jan Schaumann wrote:
> 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:49
On Tue, Apr 20, 2021 at 10:30:23AM -0400, Jan Schaumann wrote:
> RTM_MISS: Lookup failed on this address: len 200, pid 0, seq 0, errno 0,
> flags: 0x40
> locks: 0 inits: 0
> sockaddrs: 0x43
> fe80::caa:49ff:feaf:1815%xennet0 link#1
> 2600:1f18:400c:b800:bc3c:63cc:7e5d:1f96
This must be triggerin
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,
On Tue, Apr 20, 2021 at 10:09:47AM -0400, Jan Schaumann wrote:
> That's unfortunately not very revealing, as it merely
> shows the neighbor solicitations and router advertisements:
>
> IP6 fe80::7e12:b688:167c:785f > fe80::caa:49ff:feaf:1815: ICMP6, neighbor
> solicitation, who has fe80::caa:49ff:
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 dhcpcd[17397]: xennet0: fe80::caa:49f
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 dhcpcd[17397]: xennet0: fe80::caa:49ff:feaf:1815 is
> unreachable
> Ap
20 matches
Mail list logo
