Re: (Strange?) behavior of -current kernel on "ICMP6, packet too big, mtu 1450"

[Greg Troxel <gdt%lexort.com@localhost>]

Markus Kilbinger <mk%kilbi.de@localhost> writes:

> Recently I tried to connect (ssh) my -current aarch64 machine over
> ipv6 and a vxlan tunnel what didn't work as expected (connection
> timeout).

The key point is tunnel, most likely.  You didn't explain what it is
connected to and where you are coming from.

IPv6 doctine is that there is no fragementation and that Path MTU
Discovery must function.  There is a standard length (1280 I think) that
must be carried by all links.

Generally, I think NetBSD starts out with packets size for the link MTU,
and then on receipt of packet too big, reduces.  I would have expected
this to be kept track of in the the routing table, 

> On my target -current aarch64 machine I've found (tcpdump) a corresponding:
>
>   08:35:29.735126 IP6 fd01::1 > fd01::2: ICMP6, packet too big, mtu
> 1450, length 1240
>
> which produced a routing table entry on the netbsd target machine:
>
> # netstat  -f inet6 -rna | grep fd01
>   ...
>   fd01:01                link#1                         UGHD        -
>       -   1450  awge0

Your message is hard to read because it is incorrectly wrapped.

It's hard to tell what's going on because you haven't explained your
networking plan.  Those addresses are on the same link, or should be.

> resulting in a connection block for my source machine:
>
> # ping6 fd01:1
>   PING6(56=40+8+8 bytes) fd01::2 --> fd01:1
>   ping6: sendmsg: Address family not supported by protocol family
>   ping6: wrote fd01:1 16 chars, ret=-1
>
> Deleting the 'false' routing table entry manually on the netbsd target
> machine made the connection work again.
>
> So, is this the intended reaction of a netbsd kernel on such ICMP6 packets?
> My misunderstanding?

hard to say so far.

> Initiating such ssh connections from an available Linux machine does
> not show this problem / behavior (== works).
>
> Any help / comment appreciated.
> send-pr?

No, very much premature for send-pr because you have not given enough evidence
that there's a bug and there is not enough information for someone to
reproduce.

But it may well be that there is something wrong.