NetBSD Problem Report #57037
From kardel@Kardel.name Fri Sep 30 09:22:20 2022
Return-Path: <kardel@Kardel.name>
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))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 220C01A923C
for <gnats-bugs@gnats.NetBSD.org>; Fri, 30 Sep 2022 09:22:20 +0000 (UTC)
Message-Id: <20220930080455.B316644B33@Andromeda.Kardel.name>
Date: Fri, 30 Sep 2022 10:04:55 +0200 (CEST)
From: kardel@netbsd.org
Reply-To: kardel@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: unncessary and unwarranted RTM_NEWADDR for IPv6 routing messages
X-Send-Pr-Version: 3.95
>Number: 57037
>Category: kern
>Synopsis: IPv6 autoconfig causes RTM_NEWADDR messages every 2 minutes (unnecessary and unwarranted)
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Sep 30 09:25:00 +0000 2022
>Closed-Date: Fri Jan 20 06:49:41 +0000 2023
>Last-Modified: Fri Jan 20 06:49:41 +0000 2023
>Originator: kardel@netbsd.org
>Release: NetBSD 9.99.100
>Organization:
>Environment:
System: NetBSD styxnew 9.99.100 NetBSD 9.99.100 (GENERIC) #1: Sat Sep 24 09:01:07 UTC 2022 kardel@gaiatest:/src/NetBSD/current/src/obj.amd64/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
When using auto configured IPv6 addresses RTM_NEWADDR messages show up about every 2 minutes.
No intervening RTM_DELADDR messages are sent inbetween. if_watchd triggers on these causing
scripts to needlessly run on an unchanged network situation.
These message should not be sent unless a real change happens.
>How-To-Repeat:
let NetBSD autoconfigure IPv6 and watch "route monitor".
RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
sockaddrs: 0x34<NETMASK,IFP,IFA>
ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
got message of size 112 on Fri Sep 30 08:24:57 2022
#12: len 112, got message of size 120 on Fri Sep 30 08:24:57 2022
RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
sockaddrs: 0x34<NETMASK,IFP,IFA>
ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
got message of size 112 on Fri Sep 30 08:26:58 2022
#12: len 112, got message of size 120 on Fri Sep 30 08:26:58 2022
RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
sockaddrs: 0x34<NETMASK,IFP,IFA>
ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
got message of size 112 on Fri Sep 30 08:28:59 2022
#12: len 112, got message of size 120 on Fri Sep 30 08:28:59 2022
RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
sockaddrs: 0x34<NETMASK,IFP,IFA>
ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
got message of size 112 on Fri Sep 30 08:31:00 2022
#12: len 112, got message of size 120 on Fri Sep 30 08:31:00 2022
RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
sockaddrs: 0x34<NETMASK,IFP,IFA>
ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
got message of size 112 on Fri Sep 30 08:33:02 2022
#12: len 112, got message of size 120 on Fri Sep 30 08:33:02 2022
RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
sockaddrs: 0x34<NETMASK,IFP,IFA>
ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
got message of size 112 on Fri Sep 30 08:35:03 2022
#12: len 112, got message of size 120 on Fri Sep 30 08:35:03 2022
RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
sockaddrs: 0x34<NETMASK,IFP,IFA>
>Fix:
check IPv6 autoconfiguration code?
>Release-Note:
>Audit-Trail:
From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
routing messages
Date: Fri, 30 Sep 2022 13:31:42 +0200
Am Fri, Sep 30, 2022 at 09:25:01AM +0000 schrieb kardel@netbsd.org:
> >How-To-Repeat:
> let NetBSD autoconfigure IPv6 and watch "route monitor".
>
> RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
> sockaddrs: 0x34<NETMASK,IFP,IFA>
> ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
> got message of size 112 on Fri Sep 30 08:24:57 2022
> #12: len 112, got message of size 120 on Fri Sep 30 08:24:57 2022
> RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
> sockaddrs: 0x34<NETMASK,IFP,IFA>
> ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
> got message of size 112 on Fri Sep 30 08:26:58 2022
So what is the life time of the addresses? Are you sure your network
isn't forcing a renewal every minute?
Joerg
From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
routing messages
Date: Fri, 30 Sep 2022 16:42:23 +0200
SLAAC is being used (stock NetBSD)
The router advertisements list prefix info option (3), length 32 (4):
xxxx:yyyy:zzzz:aaaa:/64, Flags [onlink, auto], valid time 2592000s,
pref. time 604800s
This 2 minutes is less than the preferred life time.
The routing message is sent with each router advertisement being received.
13:37:29.518377 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
56) fe80::4e02:89ff:fe13:a456 > ff02::1: [icmp6 sum ok] ICMP6, router
advertisement, length 56
hop limit 64, Flags [none], pref high, router lifetime 360s,
reachable time 0ms, retrans timer 0ms
prefix info option (3), length 32 (4):
xxxx:yyyy:zzzz:aaaa::/64, Flags [onlink, auto], valid time 2592000s,
pref. time 604800s
source link-address option (1), length 8 (1): 4c:02:89:13:a4:56
got message of size 112 on Fri Sep 30 13:37:29 2022
#12: len 112, got message of size 120 on Fri Sep 30 13:37:29 2022
RTM_NEWADDR: address being added to iface: len 120, pid 3382, metric 0,
addrflags: 0x40<AUTOCONF>
sockaddrs: 0x34<NETMASK,IFP,IFA>
ffff:ffff:ffff:ffff:: aa:00:00:00:00:ff
xxxx:yyyy:zzzz:aaaa:bbbb:cccc:dddd:eeee
13:39:30.805386 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
56) fe80::4e02:89ff:fe13:a456 > ff02::1: [icmp6 sum ok] ICMP6, router
advertisement, length 56
hop limit 64, Flags [none], pref high, router lifetime 360s,
reachable time 0ms, retrans timer 0ms
prefix info option (3), length 32 (4):
xxxx:yyyy:zzzz:aaaa::/64, Flags [onlink, auto], valid time 2592000s,
pref. time 604800s
source link-address option (1), length 8 (1): 4c:02:89:13:a4:56
got message of size 112 on Fri Sep 30 13:39:30 2022
#12: len 112, got message of size 120 on Fri Sep 30 13:39:30 2022
RTM_NEWADDR: address being added to iface: len 120, pid 3382, metric 0,
addrflags: 0x40<AUTOCONF>
sockaddrs: 0x34<NETMASK,IFP,IFA>
ffff:ffff:ffff:ffff:: aa:00:00:00:00:ff
xxxx:yyyy:zzzz:aaaa:bbbb:cccc:dddd:eeee
13:41:32.082752 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
56) fe80::4e02:89ff:fe13:a456 > ff02::1: [icmp6 sum ok] ICMP6, router
advertisement, length 56
hop limit 64, Flags [none], pref high, router lifetime 360s,
reachable time 0ms, retrans timer 0ms
prefix info option (3), length 32 (4):
xxxx:yyyy:zzzz:aaaa::/64, Flags [onlink, auto], valid time 2592000s,
pref. time 604800s
source link-address option (1), length 8 (1): 4c:02:89:13:a4:56
got message of size 112 on Fri Sep 30 13:41:32 2022
#12: len 112, got message of size 120 on Fri Sep 30 13:41:32 2022
RTM_NEWADDR: address being added to iface: len 120, pid 3382, metric 0,
addrflags: 0x40<AUTOCONF>
sockaddrs: 0x34<NETMASK,IFP,IFA>
ffff:ffff:ffff:ffff:: aa:00:00:00:00:ff
xxxx:yyyy:zzzz:aaaa:bbbb:cccc:dddd:eeee
According to RFC4862 these router adverstisement shoul update the
preferred lifetime. Looking the the code this
seems to be the case. Especially RTM_NEWADDR is being sent on any
changes of parameters of an address.
Thus RTM_NEWADDR meas a real new address OR address parameters have
changed.
That explains why I see ifwatchd -u running the script every two minutes
even though the address itself
is not new, but the preferred lifetime was updated.
Oh, well - looks like a feature.
How can we detect the we got a genuine new address instead of updated
address parameters?
Frank
On 09/30/22 13:35, Joerg Sonnenberger wrote:
> The following reply was made to PR kern/57037; it has been noted by GNATS.
>
> From: Joerg Sonnenberger <joerg@bec.de>
> To: gnats-bugs@netbsd.org
> Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org
> Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
> routing messages
> Date: Fri, 30 Sep 2022 13:31:42 +0200
>
> Am Fri, Sep 30, 2022 at 09:25:01AM +0000 schrieb kardel@netbsd.org:
> > >How-To-Repeat:
> > let NetBSD autoconfigure IPv6 and watch "route monitor".
> >
> > RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
> > sockaddrs: 0x34<NETMASK,IFP,IFA>
> > ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
> > got message of size 112 on Fri Sep 30 08:24:57 2022
> > #12: len 112, got message of size 120 on Fri Sep 30 08:24:57 2022
> > RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
> > sockaddrs: 0x34<NETMASK,IFP,IFA>
> > ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
> > got message of size 112 on Fri Sep 30 08:26:58 2022
>
> So what is the life time of the addresses? Are you sure your network
> isn't forcing a renewal every minute?
>
> Joerg
>
From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
routing messages
Date: Fri, 30 Sep 2022 16:57:39 +0200
Looking at route.h we have:
#define RTM_NEWADDR 0x16 /* address being added to iface */
#define RTM_DELADDR 0x17 /* address being removed from iface */
#define RTM_CHGADDR 0x18 /* address properties changed */
Wouldn't RTM_CHGADDR be more appropriate for address parameter updates
when new new address is being added?
Frank
On 09/30/22 13:35, Joerg Sonnenberger wrote:
> The following reply was made to PR kern/57037; it has been noted by GNATS.
>
> From: Joerg Sonnenberger <joerg@bec.de>
> To: gnats-bugs@netbsd.org
> Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org
> Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
> routing messages
> Date: Fri, 30 Sep 2022 13:31:42 +0200
>
> Am Fri, Sep 30, 2022 at 09:25:01AM +0000 schrieb kardel@netbsd.org:
> > >How-To-Repeat:
> > let NetBSD autoconfigure IPv6 and watch "route monitor".
> >
> > RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
> > sockaddrs: 0x34<NETMASK,IFP,IFA>
> > ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
> > got message of size 112 on Fri Sep 30 08:24:57 2022
> > #12: len 112, got message of size 120 on Fri Sep 30 08:24:57 2022
> > RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
> > sockaddrs: 0x34<NETMASK,IFP,IFA>
> > ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
> > got message of size 112 on Fri Sep 30 08:26:58 2022
>
> So what is the life time of the addresses? Are you sure your network
> isn't forcing a renewal every minute?
>
> Joerg
>
From: Kengo NAKAHARA <k-nakahara@iij.ad.jp>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, kardel@netbsd.org
Cc:
Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
routing messages
Date: Mon, 3 Oct 2022 13:48:41 +0900
Hi,
Could you try the following patch and command?
====================
# sysctl -w net.inet6.ip6.param_rt_msg=0
====================
If the behavior is what you want, I will commit the patch.
========== patch from ==========
diff --git a/sys/netinet6/in6.c b/sys/netinet6/in6.c
index 9200150c568..01bb9aeeb60 100644
--- a/sys/netinet6/in6.c
+++ b/sys/netinet6/in6.c
@@ -1065,6 +1065,8 @@ in6_update_ifa1(struct ifnet *ifp, struct in6_aliasreq *ifra,
int dad_delay, was_tentative;
struct in6_ifaddr *ia = iap ? *iap : NULL;
char ip6buf[INET6_ADDRSTRLEN];
+ bool addrmaskNotChanged = false;
+ int saved_flags;
KASSERT((iap == NULL && psref == NULL) ||
(iap != NULL && psref != NULL));
@@ -1186,6 +1188,21 @@ in6_update_ifa1(struct ifnet *ifp, struct in6_aliasreq *ifra,
return 0; /* there's nothing to do */
}
+#define sin6eq(a, b) \
+ ((a)->sin6_len == sizeof(struct sockaddr_in6) && \
+ (b)->sin6_len == sizeof(struct sockaddr_in6) && \
+ IN6_ARE_ADDR_EQUAL(&(a)->sin6_addr, &(b)->sin6_addr))
+
+ if (!ip6_param_rt_msg) {
+ if (ia != NULL &&
+ sin6eq(&dst6, &ia->ia_dstaddr) &&
+ sin6eq(&ifra->ifra_prefixmask, &ia->ia_prefixmask)) {
+ addrmaskNotChanged = true;
+ saved_flags = ia->ia6_flags; /* check it later */
+ }
+ }
+#undef sin6eq
+
/*
* If this is a new address, allocate a new ifaddr and link it
* into chains.
@@ -1291,6 +1308,17 @@ in6_update_ifa1(struct ifnet *ifp, struct in6_aliasreq *ifra,
ia->ia6_lifetime.ia6t_preferred = time_uptime;
}
+ if (!ip6_param_rt_msg) {
+ /*
+ * We will not send RTM_NEWADDR if the only difference between
+ * ia and ifra is preferred/valid lifetimes, because it is not
+ * very useful for userland programs to be notified of that
+ * changes.
+ */
+ if (addrmaskNotChanged && ia->ia6_flags == saved_flags)
+ return 0;
+ }
+
if (hostIsNew) {
/*
* We need a reference to ia before calling in6_ifinit.
diff --git a/sys/netinet6/in6_proto.c b/sys/netinet6/in6_proto.c
index da6dc661851..8737b4a4f6f 100644
--- a/sys/netinet6/in6_proto.c
+++ b/sys/netinet6/in6_proto.c
@@ -551,6 +551,7 @@ int ip6_mcast_pmtu = 0; /* enable pMTU discovery for multicast? */
int ip6_v6only = 1;
int ip6_neighborgcthresh = 2048; /* Threshold # of NDP entries for GC */
int ip6_maxdynroutes = 4096; /* Max # of routes created via redirect */
+bool ip6_param_rt_msg = true; /* Send rtm for not only new addr but also parmeters */
int ip6_keepfaith = 0;
time_t ip6_log_time = 0;
diff --git a/sys/netinet6/ip6_input.c b/sys/netinet6/ip6_input.c
index e0db6596f89..0d6d14f8763 100644
--- a/sys/netinet6/ip6_input.c
+++ b/sys/netinet6/ip6_input.c
@@ -1803,6 +1803,14 @@ sysctl_net_inet6_ip6_setup(struct sysctllog **clog)
NULL, 1, &ip6_maxdynroutes, 0,
CTL_NET, PF_INET6, IPPROTO_IPV6,
CTL_CREATE, CTL_EOL);
+ sysctl_createv(clog, 0, NULL, NULL,
+ CTLFLAG_PERMANENT|CTLFLAG_READWRITE,
+ CTLTYPE_BOOL, "param_rt_msg",
+ SYSCTL_DESCR("Send routing message for not only"
+ " new address but also parmeters"),
+ NULL, 0, &ip6_param_rt_msg, 0,
+ CTL_NET, PF_INET6, IPPROTO_IPV6,
+ CTL_CREATE, CTL_EOL);
}
void
diff --git a/sys/netinet6/ip6_var.h b/sys/netinet6/ip6_var.h
index 6508e67e8f0..1a0d144568c 100644
--- a/sys/netinet6/ip6_var.h
+++ b/sys/netinet6/ip6_var.h
@@ -257,6 +257,7 @@ extern int ip6_mcast_pmtu; /* enable pMTU discovery for multicast? */
extern int ip6_v6only;
extern int ip6_neighborgcthresh; /* Threshold # of NDP entries for GC */
extern int ip6_maxdynroutes; /* Max # of routes created via redirect */
+extern bool ip6_param_rt_msg; /* Send rtm for not only new addr but also parmeters */
extern struct socket *ip6_mrouter; /* multicast routing daemon */
========== patch to ==========
Thanks,
On 2022/10/01 0:00, Frank Kardel wrote:
> The following reply was made to PR kern/57037; it has been noted by GNATS.
>
> From: Frank Kardel <kardel@netbsd.org>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
> routing messages
> Date: Fri, 30 Sep 2022 16:57:39 +0200
>
> Looking at route.h we have:
>
> #define RTM_NEWADDR 0x16 /* address being added to iface */
> #define RTM_DELADDR 0x17 /* address being removed from iface */
> #define RTM_CHGADDR 0x18 /* address properties changed */
>
> Wouldn't RTM_CHGADDR be more appropriate for address parameter updates
> when new new address is being added?
>
> Frank
>
>
> On 09/30/22 13:35, Joerg Sonnenberger wrote:
> > The following reply was made to PR kern/57037; it has been noted by GNATS.
> >
> > From: Joerg Sonnenberger <joerg@bec.de>
> > To: gnats-bugs@netbsd.org
> > Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
> > netbsd-bugs@netbsd.org
> > Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
> > routing messages
> > Date: Fri, 30 Sep 2022 13:31:42 +0200
> >
> > Am Fri, Sep 30, 2022 at 09:25:01AM +0000 schrieb kardel@netbsd.org:
> > > >How-To-Repeat:
> > > let NetBSD autoconfigure IPv6 and watch "route monitor".
> > >
> > > RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
> > > sockaddrs: 0x34<NETMASK,IFP,IFA>
> > > ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
> > > got message of size 112 on Fri Sep 30 08:24:57 2022
> > > #12: len 112, got message of size 120 on Fri Sep 30 08:24:57 2022
> > > RTM_NEWADDR: address being added to iface: len 120, pid 1709, metric 0, addrflags: 0x40<AUTOCONF>
> > > sockaddrs: 0x34<NETMASK,IFP,IFA>
> > > ffff:ffff:ffff:ffff:: aa:00:00:00:00:01 xxxx:yyyy:zzzz:rrrr:ssss:tttt:uuuu:vvvv
> > > got message of size 112 on Fri Sep 30 08:26:58 2022
> >
> > So what is the life time of the addresses? Are you sure your network
> > isn't forcing a renewal every minute?
> >
> > Joerg
> >
>
--
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.
Device Engineering Section,
Product Division,
Technology Unit
Kengo NAKAHARA <k-nakahara@iij.ad.jp>
From: Frank Kardel <kardel@netbsd.org>
To: Kengo NAKAHARA <k-nakahara@iij.ad.jp>, gnats-bugs <gnats-bugs@NetBSD.org>
Cc:
Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
routing messages
Date: Fri, 7 Oct 2022 16:19:43 +0200
This is a multi-part message in MIME format.
--------------1669377E74E9CD45AF9CF9D8
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
I debugged the patch and the issue was the the comparison was with dst6
and dst addrs. Instead the actual addresses needed to be compared.
The corrected patch is attached.
Best regards,
Frank
On 10/06/22 08:46, Kengo NAKAHARA wrote:
> Hi,
>
> Thank you for your testing!
>
> Sorry I can't help you. Hmm, the patch may be old, I will review
> and test it again.
>
>
> Thanks,
>
> On 2022/10/06 15:34, Frank Kardel wrote:
>> Hi!
>>
>> Thanks for the patch.
>>
>> Unfortunately I still see RTM_NEWADDRs after setting
>> net.inet6.ip6.param_rt_msg=0
>>
>> This needs a bit more debugging - maybe I get to that after may $DAYJOB.
>>
>> Best regards,
>>
>> Frank
>>
>>
>> On 10/06/22 01:51, Kengo NAKAHARA wrote:
>>> sysctl -w net.inet6.ip6.param_rt_msg=0
>>
>
--------------1669377E74E9CD45AF9CF9D8
Content-Type: application/gzip;
name="20221007-param-rt-msg.patch.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="20221007-param-rt-msg.patch.gz"
H4sICH0zQGMAAzIwMjIxMDA3LXBhcmFtLXJ0LW1zZy5tc2cAvVZtc9pGEP4sfsXGmXHBgJGE
wRjGqalNMkwd7AJpJtN2NId0ghsLid4d2G6d/97dk3izsZMmM9EA4l72uX15dvdOT7/7yfXP
BxCKiDeh4i+UTBJdUdKvqHtVibkW+K1XRFw/9EuLnORaCr4Q8RgkvpRIYnAO3UY9F4gwhPIc
ytKMwUjkyuUyPAWyXBsGfAau7bpgu0232qweQ9nGx0rRisXiLrljuPJ1KuYcNe1G03ZTsdzZ
GZQdu14r1aFo3g04O8uBJWINAQu8gEfsvgS3THmax5ppseAtXFdazhES4T0RsiCQcCAYnIJg
M/iZ/s+gCb0Pl5e02Z8wCWJWH83DP7q9zrDutS8u+oNh/7LT+6uVK1qjJImAUKZM3fQSfT5h
8ZgHiBeySHHaQgoptuCBF0ZsrBAWgX9tDwad/jCfp/NOT82BsL8PMyV5uJwowMMD7gV8zL5X
j/dlE4VCK3WH06gbdziNRsl1Un9YFoZwLmOwW1A5AD3hkv+kIE70hIKqEwgSOKjgzs+oWfF1
wEMMACh0EP87z0owKsCfaEY+zwrlNzTtRTwmFZX4hydhPnOoSvwbcoSHOwqkIglBfvQNQt0e
+rnfMb72Or99aF/m99en0/4S7K+RaaJQyBXJ1yHkX2G8vBmTbOpJ7U3VuAD/4pJZw0ivnUiT
5NvM1H0RSlZ+Q7/LMwSN01HhZYEZhkPcEQnWYuu5QqaCtZMp6ApDFMvaoIlhJMHUM9oARc+f
cP8GhIaIaS4pbCj2GX/w+3oeY+wy5dAbYFUOiD0H0A0x7EIBfhjE/NYQlitVAhZFiY9Q2XyW
ECwOIBIxHZQCIIUTPJuJWB2mTHNPHMO0qt0oOccZ05YKRyLELJ7yQxxo4wYuZWoqznrzGb1a
S8a9GDQ0gZx+AB853IooIt6C4qhgf/je63U+EkdQb+I1JHF0D1SWkOKxz2HE9S3ncYaAsSfD
KFzkiZValQWLBBmcKo1eGXGfzRUnPwuTKRnCgst7wIVwHkGYSPorI8KcyWSMqivKphEnCREK
NDghvdhS3DcRRw+aYWXJyR2cwETYCr5JnDU3CoYsq7ROw0+lD9EmidJd1eO35ECwUg5kDow5
YjMwhhsHobrolRFHYzj4SAaqCGllFLHQh7kuUuqu+aQwY0wTnWC1//5m9NXdaHnmsz0JObnV
k3AMm7ru6kzLRau61Z5q1abTWLUnAt7VnlbCLzepWs2kCr3SRKGGQHRf1A1hT8FprSdjLsaT
USLHvp5gjk5w2bWPGqZ2D81MEgXwmqjVu7gG7GzoCmXo+O7c1PEl0pTdBfexTOaaUzU5sk/q
BuU9u0vlsyVfcqwAASwEUSMQkqMxRE/T2x7n5bJeEdKA8lDqqTmdEtPYsywwMJprLDAqAZSf
cqxXyui31vCG81nIhCYjkcZpdUiXomTs0TBd2UlD3CXi2Vz/SBquz3z+auTWtq9Gbg02dX1K
w/Wi5W7QsNqs2U3bXt+SEPgpDTeEv3BXathVU7Lp7RxlJRvShzpiCRzqXY+YUwK7tLHxfHiJ
VXdYguu3nrkQlaB7fd2/Gl553evf64+3nvc77WGnZP53ri4LVKtQf19HXkq7Rd7HUNMhmQ7m
d9loU5S3l+133nWn/77d6/SGD8sZhL742O8i/Pb24afrjvfL1RWC7W0yd29z3+DTgHS66AzO
+/m9lMhoL8USW4BiY75F6j1TcVFub7N/7mD4XmHzlNQkO3PrpjLGrcWvd2vxC24FaqWwSETw
bLIsmDyc/NBUMSc+mygnzlaenDiw1nJnkpglC28b7fmYaO6A62KCNKvuKkcQc2eKpKIvJ4hb
O6b8oFdap/kdRjSmamWty3Xryfzjit2yvrpUP0LazLv/V6ozIKrY1mOqpTfHb63VKyU3buwc
DzX6GrVki26aMJ1HWvhM6VUiBYxPMdKI8x8g5EqetQ4AAA==
--------------1669377E74E9CD45AF9CF9D8--
From: Kengo NAKAHARA <k-nakahara@iij.ad.jp>
To: Frank Kardel <kardel@netbsd.org>, gnats-bugs <gnats-bugs@NetBSD.org>
Cc:
Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
routing messages
Date: Tue, 11 Oct 2022 16:05:54 +0900
Hi,
Thank you for your fixing!
Is the behavior is what you want?
Thanks,
On 2022/10/07 23:19, Frank Kardel wrote:
> Hi,
>
> I debugged the patch and the issue was the the comparison was with dst6 and dst addrs. Instead the actual addresses needed to be compared.
>
> The corrected patch is attached.
>
> Best regards,
>
> Frank
>
>
> On 10/06/22 08:46, Kengo NAKAHARA wrote:
>> Hi,
>>
>> Thank you for your testing!
>>
>> Sorry I can't help you. Hmm, the patch may be old, I will review
>> and test it again.
>>
>>
>> Thanks,
>>
>> On 2022/10/06 15:34, Frank Kardel wrote:
>>> Hi!
>>>
>>> Thanks for the patch.
>>>
>>> Unfortunately I still see RTM_NEWADDRs after setting net.inet6.ip6.param_rt_msg=0
>>>
>>> This needs a bit more debugging - maybe I get to that after may $DAYJOB.
>>>
>>> Best regards,
>>>
>>> Frank
>>>
>>>
>>> On 10/06/22 01:51, Kengo NAKAHARA wrote:
>>>> sysctl -w net.inet6.ip6.param_rt_msg=0
>>>
>>
>
--
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.
Device Engineering Section,
Product Division,
Technology Unit
Kengo NAKAHARA <k-nakahara@iij.ad.jp>
From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
routing messages
Date: Wed, 12 Oct 2022 11:33:53 +0200
Hi,
yes. It follows the principle of least astonishment. So that is now fine.
I was wondering whether parameter changes should be announced via
#define RTM_CHGADDR 0x18 /* address properties changed */
but I currently have no idea how widely the interface is defined/used
and what the
breakage would be.
RTM_CHGADDR sounds in the comment the this could be right for parameter
changes, but
I am no up to date on the semantics of that. Maybe someone (tm) could
shed more light on that.
Best regards,
Frank
On 10/11/22 09:40, Kengo NAKAHARA wrote:
> The following reply was made to PR kern/57037; it has been noted by GNATS.
>
> From: Kengo NAKAHARA <k-nakahara@iij.ad.jp>
> To: Frank Kardel <kardel@netbsd.org>, gnats-bugs <gnats-bugs@NetBSD.org>
> Cc:
> Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
> routing messages
> Date: Tue, 11 Oct 2022 16:05:54 +0900
>
> Hi,
>
> Thank you for your fixing!
>
> Is the behavior is what you want?
>
>
> Thanks,
>
> On 2022/10/07 23:19, Frank Kardel wrote:
> > Hi,
> >
> > I debugged the patch and the issue was the the comparison was with dst6 and dst addrs. Instead the actual addresses needed to be compared.
> >
> > The corrected patch is attached.
> >
> > Best regards,
> >
> > Â Frank
> >
> >
> > On 10/06/22 08:46, Kengo NAKAHARA wrote:
> >> Hi,
> >>
> >> Thank you for your testing!
> >>
> >> Sorry I can't help you. Hmm, the patch may be old, I will review
> >> and test it again.
> >>
> >>
> >> Thanks,
> >>
> >> On 2022/10/06 15:34, Frank Kardel wrote:
> >>> Hi!
> >>>
> >>> Thanks for the patch.
> >>>
> >>> Unfortunately I still see RTM_NEWADDRs after setting net.inet6.ip6.param_rt_msg=0
> >>>
> >>> This needs a bit more debugging - maybe I get to that after may $DAYJOB.
> >>>
> >>> Best regards,
> >>>
> >>> Â Â Frank
> >>>
> >>>
> >>> On 10/06/22 01:51, Kengo NAKAHARA wrote:
> >>>> sysctl -w net.inet6.ip6.param_rt_msg=0
> >>>
> >>
> >
>
> --
> //////////////////////////////////////////////////////////////////////
> Internet Initiative Japan Inc.
>
> Device Engineering Section,
> Product Division,
> Technology Unit
>
> Kengo NAKAHARA <k-nakahara@iij.ad.jp>
>
>
From: Kengo NAKAHARA <k-nakahara@iij.ad.jp>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, kardel@netbsd.org
Cc:
Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
routing messages
Date: Mon, 17 Oct 2022 19:17:22 +0900
Hi,
On 2022/10/12 18:35, Frank Kardel wrote:
> The following reply was made to PR kern/57037; it has been noted by GNATS.
>
> From: Frank Kardel <kardel@netbsd.org>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
> routing messages
> Date: Wed, 12 Oct 2022 11:33:53 +0200
>
> Hi,
>
> yes. It follows the principle of least astonishment. So that is now fine.
>
> I was wondering whether parameter changes should be announced via
>
> #define RTM_CHGADDR 0x18 /* address properties changed */
>
> but I currently have no idea how widely the interface is defined/used
> and what the
> breakage would be.
> RTM_CHGADDR sounds in the comment the this could be right for parameter
> changes, but
> I am no up to date on the semantics of that. Maybe someone (tm) could
> shed more light on that.
I have considered about RTM_CHGADDR idea, however I cannot come up with
a good design. So, I change net.inet6.ip6.param_rt_msg value type from
bool to int for future expandability, and the values are consisted of
- 0 : don't send parameter changing routing message
- 1(default) : send parameter changing routing message by RTM_NEWADDR
(same as before)
Maybe someone (tm) will implement
- 2 : send parameter changing routing message by RTM_CHGADDR (or better way?)
Here is the updated patch
https://www.netbsd.org/~knakahara/20221017-param-rt-msg.patch
If there is no objection, I will commit this patch.
Thanks,
> Best regards,
> Frank
>
> On 10/11/22 09:40, Kengo NAKAHARA wrote:
> > The following reply was made to PR kern/57037; it has been noted by GNATS.
> >
> > From: Kengo NAKAHARA <k-nakahara@iij.ad.jp>
> > To: Frank Kardel <kardel@netbsd.org>, gnats-bugs <gnats-bugs@NetBSD.org>
> > Cc:
> > Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
> > routing messages
> > Date: Tue, 11 Oct 2022 16:05:54 +0900
> >
> > Hi,
> >
> > Thank you for your fixing!
> >
> > Is the behavior is what you want?
> >
> >
> > Thanks,
> >
> > On 2022/10/07 23:19, Frank Kardel wrote:
> > > Hi,
> > >
> > > I debugged the patch and the issue was the the comparison was with dst6 and dst addrs. Instead the actual addresses needed to be compared.
> > >
> > > The corrected patch is attached.
> > >
> > > Best regards,
> > >
> > > Â Frank
> > >
> > >
> > > On 10/06/22 08:46, Kengo NAKAHARA wrote:
> > >> Hi,
> > >>
> > >> Thank you for your testing!
> > >>
> > >> Sorry I can't help you. Hmm, the patch may be old, I will review
> > >> and test it again.
> > >>
> > >>
> > >> Thanks,
> > >>
> > >> On 2022/10/06 15:34, Frank Kardel wrote:
> > >>> Hi!
> > >>>
> > >>> Thanks for the patch.
> > >>>
> > >>> Unfortunately I still see RTM_NEWADDRs after setting net.inet6.ip6.param_rt_msg=0
> > >>>
> > >>> This needs a bit more debugging - maybe I get to that after may $DAYJOB.
> > >>>
> > >>> Best regards,
> > >>>
> > >>> Â Â Frank
> > >>>
> > >>>
> > >>> On 10/06/22 01:51, Kengo NAKAHARA wrote:
> > >>>> sysctl -w net.inet6.ip6.param_rt_msg=0
> > >>>
> > >>
> > >
> >
> > --
> > //////////////////////////////////////////////////////////////////////
> > Internet Initiative Japan Inc.
> >
> > Device Engineering Section,
> > Product Division,
> > Technology Unit
> >
> > Kengo NAKAHARA <k-nakahara@iij.ad.jp>
> >
> >
>
--
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.
Device Engineering Section,
Product Division,
Technology Unit
Kengo NAKAHARA <k-nakahara@iij.ad.jp>
From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
routing messages
Date: Mon, 17 Oct 2022 12:56:46 +0200
I am fine with that.
Frank
On 10/17/22 12:35, Kengo NAKAHARA wrote:
> The following reply was made to PR kern/57037; it has been noted by GNATS.
>
> From: Kengo NAKAHARA <k-nakahara@iij.ad.jp>
> To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org, kardel@netbsd.org
> Cc:
> Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
> routing messages
> Date: Mon, 17 Oct 2022 19:17:22 +0900
>
> Hi,
>
> On 2022/10/12 18:35, Frank Kardel wrote:
> > The following reply was made to PR kern/57037; it has been noted by GNATS.
> >
> > From: Frank Kardel <kardel@netbsd.org>
> > To: gnats-bugs@netbsd.org
> > Cc:
> > Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
> > routing messages
> > Date: Wed, 12 Oct 2022 11:33:53 +0200
> >
> > Hi,
> >
> > yes. It follows the principle of least astonishment. So that is now fine.
> >
> > I was wondering whether parameter changes should be announced via
> >
> > #define RTM_CHGADDR 0x18 /* address properties changed */
> >
> > but I currently have no idea how widely the interface is defined/used
> > and what the
> > breakage would be.
> > RTM_CHGADDR sounds in the comment the this could be right for parameter
> > changes, but
> > I am no up to date on the semantics of that. Maybe someone (tm) could
> > shed more light on that.
>
> I have considered about RTM_CHGADDR idea, however I cannot come up with
> a good design. So, I change net.inet6.ip6.param_rt_msg value type from
> bool to int for future expandability, and the values are consisted of
> - 0 : don't send parameter changing routing message
> - 1(default) : send parameter changing routing message by RTM_NEWADDR
> (same as before)
> Maybe someone (tm) will implement
> - 2 : send parameter changing routing message by RTM_CHGADDR (or better way?)
>
> Here is the updated patch
> https://www.netbsd.org/~knakahara/20221017-param-rt-msg.patch
>
> If there is no objection, I will commit this patch.
>
>
> Thanks,
>
> > Best regards,
> > Frank
> >
> > On 10/11/22 09:40, Kengo NAKAHARA wrote:
> > > The following reply was made to PR kern/57037; it has been noted by GNATS.
> > >
> > > From: Kengo NAKAHARA <k-nakahara@iij.ad.jp>
> > > To: Frank Kardel <kardel@netbsd.org>, gnats-bugs <gnats-bugs@NetBSD.org>
> > > Cc:
> > > Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
> > > routing messages
> > > Date: Tue, 11 Oct 2022 16:05:54 +0900
> > >
> > > Hi,
> > >
> > > Thank you for your fixing!
> > >
> > > Is the behavior is what you want?
> > >
> > >
> > > Thanks,
> > >
> > > On 2022/10/07 23:19, Frank Kardel wrote:
> > > > Hi,
> > > >
> > > > I debugged the patch and the issue was the the comparison was with dst6 and dst addrs. Instead the actual addresses needed to be compared.
> > > >
> > > > The corrected patch is attached.
> > > >
> > > > Best regards,
> > > >
> > > > Â Frank
> > > >
> > > >
> > > > On 10/06/22 08:46, Kengo NAKAHARA wrote:
> > > >> Hi,
> > > >>
> > > >> Thank you for your testing!
> > > >>
> > > >> Sorry I can't help you. Hmm, the patch may be old, I will review
> > > >> and test it again.
> > > >>
> > > >>
> > > >> Thanks,
> > > >>
> > > >> On 2022/10/06 15:34, Frank Kardel wrote:
> > > >>> Hi!
> > > >>>
> > > >>> Thanks for the patch.
> > > >>>
> > > >>> Unfortunately I still see RTM_NEWADDRs after setting net.inet6.ip6.param_rt_msg=0
> > > >>>
> > > >>> This needs a bit more debugging - maybe I get to that after may $DAYJOB.
> > > >>>
> > > >>> Best regards,
> > > >>>
> > > >>> Â Â Frank
> > > >>>
> > > >>>
> > > >>> On 10/06/22 01:51, Kengo NAKAHARA wrote:
> > > >>>> sysctl -w net.inet6.ip6.param_rt_msg=0
> > > >>>
> > > >>
> > > >
> > >
> > > --
> > > //////////////////////////////////////////////////////////////////////
> > > Internet Initiative Japan Inc.
> > >
> > > Device Engineering Section,
> > > Product Division,
> > > Technology Unit
> > >
> > > Kengo NAKAHARA <k-nakahara@iij.ad.jp>
> > >
> > >
> >
>
> --
> //////////////////////////////////////////////////////////////////////
> Internet Initiative Japan Inc.
>
> Device Engineering Section,
> Product Division,
> Technology Unit
>
> Kengo NAKAHARA <k-nakahara@iij.ad.jp>
>
>
From: "Kengo NAKAHARA" <knakahara@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57037 CVS commit: src
Date: Mon, 24 Oct 2022 01:54:19 +0000
Module Name: src
Committed By: knakahara
Date: Mon Oct 24 01:54:19 UTC 2022
Modified Files:
src/share/man/man7: sysctl.7
src/sys/netinet6: in6.c in6_proto.c ip6_input.c ip6_var.h
Log Message:
Fix PR kern/57037
Be able to change the behavior sending parameter changing routing messages.
When set net.inet6.ip6.param_rt_msg=0, don't send parameter changing
routing messages.
When set net.inet6.ip6.param_rt_msg=1(default), send parameter changing
routing messages by RTM_NEWADDR.
To generate a diff of this commit:
cvs rdiff -u -r1.161 -r1.162 src/share/man/man7/sysctl.7
cvs rdiff -u -r1.286 -r1.287 src/sys/netinet6/in6.c
cvs rdiff -u -r1.129 -r1.130 src/sys/netinet6/in6_proto.c
cvs rdiff -u -r1.225 -r1.226 src/sys/netinet6/ip6_input.c
cvs rdiff -u -r1.91 -r1.92 src/sys/netinet6/ip6_var.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 02 Jan 2023 03:23:55 +0000
State-Changed-Why:
Committed; is this done?
From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/57037 (IPv6 autoconfig causes RTM_NEWADDR messages every 2
minutes (unnecessary and unwarranted))
Date: Thu, 5 Jan 2023 09:58:28 +0100
Yes. now configurable with sysctl.
We can close the bug and re-visit the RTM_CHGADDR issue at a later point
in time.
Frank
On 01/02/23 04:23, dholland@NetBSD.org wrote:
> Synopsis: IPv6 autoconfig causes RTM_NEWADDR messages every 2 minutes (unnecessary and unwarranted)
>
> State-Changed-From-To: open->feedback
> State-Changed-By: dholland@NetBSD.org
> State-Changed-When: Mon, 02 Jan 2023 03:23:55 +0000
> State-Changed-Why:
> Committed; is this done?
>
>
>
State-Changed-From-To: feedback->closed
State-Changed-By: kardel@NetBSD.org
State-Changed-When: Fri, 20 Jan 2023 06:49:41 +0000
State-Changed-Why:
fixed
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2023
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home