NetBSD Problem Report #59664

From christos@astron.com  Sun Sep 21 17:13:42 2025
Return-Path: <christos@astron.com>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id EB36E1A9239
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 21 Sep 2025 17:13:41 +0000 (UTC)
Message-Id: <20250921170647.6DC096C28F@quasar.astron.com>
Date: Sun, 21 Sep 2025 17:06:47 +0000 (UTC)
From: christos@zoulas.com
Reply-To: christos@zoulas.com
To: gnats-bugs@NetBSD.org
Subject: kernel keeps spewing can't handle af18
X-Send-Pr-Version: 3.95

>Number:         59664
>Category:       kern
>Synopsis:       kernel keeps spewing can't handle af18
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Sep 21 17:15:00 +0000 2025
>Last-Modified:  Fri Nov 14 13:25:01 +0000 2025
>Originator:     Christos Zoulas
>Release:        NetBSD 11.99.2
>Organization:
	Network Spammers, LLC.
>Environment:
System: NetBSD quasar.astron.com 11.99.2 NetBSD 11.99.2 (QUASAR) #55: Sun Sep 21 10:45:27 EDT 2025 christos@quasar.astron.com:/usr/src/sys/arch/amd64/compile/QUASAR amd64
Architecture: x86_64
Machine: amd64
>Description:
	Since early August I think the kernel has been spewing:

[  6997.112809] ether_output: wm1: can't handle af18 (link: link#2)
[  6997.159684] ether_output: wm1: can't handle af18 (link: link#2)
[  6998.147196] ether_output: wm1: can't handle af18 (link: link#2)
[  6998.391980] ether_output: wm1: can't handle af18 (link: link#2)
[  6998.981565] ether_output: wm1: can't handle af18 (link: link#2)

Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use    Mtu Interface
default            68.173.96.1        UG          -        -      -  wm0
10/8               192.168.2.9        UGS         -        -      -  wm1
10.2.0/24          10.2.0.1           U           -        -      -  wg0
10.2.0.1           wg0                UHl         -        -      -  wg0
68.173.96/21       link#1             UC          -        -      -  wm0
68.173.98.100      link#1             UHl         -        -      -  lo0
100.64/10          192.168.2.9        UGS         -        -      -  wm1
127/8              127.0.0.1          UGRS        -        -  33624  lo0
127.0.0.1          lo0                UHl         -        -  33624  lo0
172.16/12          192.168.2.9        UGS         -        -      -  wm1
192.168/16         192.168.2.9        UGS         -        -      -  wm1
192.168.2/24       link#2             UC          -        -      -  wm1
192.168.2.4        link#2             UHl         -        -      -  lo0
192.168.3/24       10.2.0.2           UGS         -        -      -  wg0
>How-To-Repeat:
	Nothing to do
>Fix:
	Yes, please.

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/59664: kernel keeps spewing can't handle af18
Date: Mon, 22 Sep 2025 10:06:11 +0200

 On Sun, Sep 21, 2025 at 05:15:00PM +0000, christos@zoulas.com wrote:
 > 	Since early August I think the kernel has been spewing:
 > 
 > [  6997.112809] ether_output: wm1: can't handle af18 (link: link#2)
 > [  6997.159684] ether_output: wm1: can't handle af18 (link: link#2)
 > [  6998.147196] ether_output: wm1: can't handle af18 (link: link#2)
 > [  6998.391980] ether_output: wm1: can't handle af18 (link: link#2)
 > [  6998.981565] ether_output: wm1: can't handle af18 (link: link#2)

 Could you add a Debugger() call and then get a backtrace and continue?

 We can probably clone a minor variation of the AF_UNSPEC case for AF_LINK,
 but it would be interesting to see where ethere_output is called from with
 this adress family.

 Martin

 Index: if_ethersubr.c
 ===================================================================
 RCS file: /cvsroot/src/sys/net/if_ethersubr.c,v
 retrieving revision 1.330
 diff -u -p -r1.330 if_ethersubr.c
 --- if_ethersubr.c	23 Apr 2025 12:17:05 -0000	1.330
 +++ if_ethersubr.c	22 Sep 2025 08:05:40 -0000
 @@ -377,6 +377,7 @@ ether_output(struct ifnet * const ifp0, 
  	default:
  		printf("%s: can't handle af%d\n", ifp->if_xname,
  		    dst->sa_family);
 +		Debugger();
  		senderr(EAFNOSUPPORT);
  	}


From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/59664: kernel keeps spewing can't handle af18
Date: Tue, 23 Sep 2025 10:56:57 -0400

 This is where it is coming from:

 [  1908.232698] ether_output() at netbsd:ether_output+0x494
 [  1908.232698] ip6_forward() at netbsd:ip6_forward+0x2d2
 [  1908.233740] ip6intr() at netbsd:ip6intr+0xef4
 [  1908.233740] softint_dispatch() at netbsd:softint_dispatch+0x112
 [  1908.234781] DDB lost frame for netbsd:Xsoftintr+0x4c, trying 
 0xffffa8124c1dd0f0
 [  1908.234781] Xsoftintr() at netbsd:Xsoftintr+0x4c
 [  1908.234781] --- interrupt ---
 [  1908.234781] 0:


 christos

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/59664: kernel keeps spewing can't handle af18
Date: Tue, 23 Sep 2025 20:07:49 +0200

 This is strange and I see no relevant changes in that time.

 Can you reproduce it with NPF disabled?
 Can you tcpdump and check if it correlates with NDP traffic?

 Martin

From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: kern/59664: kernel keeps spewing can't handle af18
Date: Tue, 23 Sep 2025 14:51:04 -0400

 It does not have to do with npf I think. It comes from ip_forward.c:

          if (rt->rt_flags & RTF_GATEWAY)
                  dst = (struct sockaddr_in6 *)rt->rt_gateway;

 and the first entry in the following which has the Gateway bit set:

 $ netstat -rn -f inet6 | grep link#2
 2603:7000:2600:320a::/64                link#2                         
 UGC         -        -  33624  wm1
 2603:7000:2600:320a::1                  link#2                         
 UHl         -        -      -  lo0
 fe80::%wm1/64                           link#2                         
 UC          -        -      -  wm1
 fe80::b696:91ff:fe41:dc87               link#2                         
 UHl         -        -      -  lo0
 ff01:2::/32                             link#2                         
 UC          -        -      -  wm1
 ff02::%wm1/32                           link#2                         
 UC          -        -      -  wm1

 This is a delegated /64 from Spectrum.

 christos

From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/59664: kernel keeps spewing can't handle af18
Date: Tue, 23 Sep 2025 16:06:19 -0400

 Solved: It is dhcpcd's fault. Reverting to the version from 2025-03-01 
 does not set the gateway bit in the route:

 2603:7000:2600:320a::/64                link#2                         
 UC          -        -      -  wm1


 christos

More logs:
https://www.zoulas.com/~christos/NetBSD/route-monitor-2025-09-24.log
https://www.zoulas.com/~christos/NetBSD/dhcpcd-2025-09-24.log

This avoids the problem:

Index: if-bsd.c
===================================================================
RCS file: /cvsroot/src/external/bsd/dhcpcd/dist/src/if-bsd.c,v
retrieving revision 1.34
diff -u -p -u -r1.34 if-bsd.c
--- if-bsd.c    16 May 2025 13:17:43 -0000      1.34
+++ if-bsd.c    22 Oct 2025 20:31:25 -0000
@@ -786,7 +786,7 @@ if_route(unsigned char cmd, const struct
                                rtm->rtm_flags &= ~RTF_HOST;
                        }
 #endif
-               } else
+               } else if (!sa_is_loopback(&rt->rt_gateway))
                        rtm->rtm_flags |= RTF_GATEWAY;

                if (rt->rt_dflags & RTDF_STATIC)

But why does dhcpcd now try to add a loopback route, where before it did not?


From: "Roy Marples" <roy@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59664 CVS commit: src/external/bsd/dhcpcd/dist/src
Date: Sun, 2 Nov 2025 06:56:17 +0000

 Module Name:	src
 Committed By:	roy
 Date:		Sun Nov  2 06:56:17 UTC 2025

 Modified Files:
 	src/external/bsd/dhcpcd/dist/src: route.c

 Log Message:
 dhcpcd: For our routing, RTF_CONNECTED is the same as RTF_CLONING.

 If we change the route, we want to flush anything dynamically created
 which includes the flags on the route.

 May fix PR kern/59664


 To generate a diff of this commit:
 cvs rdiff -u -r1.2 -r1.3 src/external/bsd/dhcpcd/dist/src/route.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Roy Marples" <roy@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59664 CVS commit: src/external/bsd/dhcpcd/dist/src
Date: Thu, 13 Nov 2025 14:51:14 +0000

 Module Name:	src
 Committed By:	roy
 Date:		Thu Nov 13 14:51:14 UTC 2025

 Modified Files:
 	src/external/bsd/dhcpcd/dist/src: if-bsd.c route.c

 Log Message:
 dhcpcd: delete+add routes when changing RTF_CONNECTED/RTF_GATEWAY

 Reject routes have RTF_GATEWAY, non reject routes do not.
 If changing from one to another, we need to delete rather than change
 because the kernel preserves some route flags such as RTF_GATEWAY.

 Fixes PR kern/59664


 To generate a diff of this commit:
 cvs rdiff -u -r1.34 -r1.35 src/external/bsd/dhcpcd/dist/src/if-bsd.c
 cvs rdiff -u -r1.3 -r1.4 src/external/bsd/dhcpcd/dist/src/route.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59664 CVS commit: [netbsd-11] src/external/bsd/dhcpcd/dist/src
Date: Fri, 14 Nov 2025 13:22:49 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Fri Nov 14 13:22:49 UTC 2025

 Modified Files:
 	src/external/bsd/dhcpcd/dist/src [netbsd-11]: if-bsd.c route.c

 Log Message:
 Pull up following revision(s) (requested by roy in ticket #83):

 	external/bsd/dhcpcd/dist/src/if-bsd.c: revision 1.35
 	external/bsd/dhcpcd/dist/src/route.c: revision 1.3
 	external/bsd/dhcpcd/dist/src/route.c: revision 1.4

 dhcpcd: For our routing, RTF_CONNECTED is the same as RTF_CLONING.

 If we change the route, we want to flush anything dynamically created
 which includes the flags on the route.
 May fix PR kern/59664

 dhcpcd: delete+add routes when changing RTF_CONNECTED/RTF_GATEWAY

 Reject routes have RTF_GATEWAY, non reject routes do not.
 If changing from one to another, we need to delete rather than change
 because the kernel preserves some route flags such as RTF_GATEWAY.

 Fixes PR kern/59664


 To generate a diff of this commit:
 cvs rdiff -u -r1.34 -r1.34.2.1 src/external/bsd/dhcpcd/dist/src/if-bsd.c
 cvs rdiff -u -r1.2 -r1.2.2.1 src/external/bsd/dhcpcd/dist/src/route.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search