daily CVS update output
Updating src tree: P src/dist/pf/share/man/man4/pflog.4 P src/dist/pf/share/man/man4/pfsync.4 P src/dist/pf/share/man/man5/pf.conf.5 P src/dist/pf/share/man/man5/pf.os.5 P src/sys/arch/amd64/include/pmap.h P src/sys/arch/arm/fdt/files.fdt P src/sys/arch/evbarm/conf/files.exynos P src/sys/arch/i386/stand/efiboot/panic.c P src/sys/arch/macppc/stand/ofwboot/Locore.c P src/sys/arch/powerpc/oea/ofw_autoconf.c P src/sys/arch/usermode/conf/Makefile.usermode P src/sys/arch/usermode/conf/kern.ldscript P src/usr.sbin/npf/npfctl/npf.conf.5 Updating xsrc tree: Killing core files: Updating tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting...pax: Unable to access src/gnu (No such file or directory) pax: WARNING! These file names were not selected: src/gnu done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc: collecting... replacing... done Updating release-7 src tree (netbsd-7): Updating release-7 xsrc tree (netbsd-7): Updating release-7 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting... replacing... done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src/x11: collecting... replacing... done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc/xfree: collecting... replacing... done xsrc: collecting... replacing... done Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.1 P sys/arch/xen/xen/xennetback_xenbus.c P sys/net/if_tun.c P sys/netinet6/nd6_rtr.c Updating release-8 xsrc tree (netbsd-8): Updating release-8 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting...pax: Unable to access src/gnu (No such file or directory) pax: WARNING! These file names were not selected: src/gnu done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... do
Re: if_addrflags6: Can't assign requested address
On 18/08/2018 03:29, SAITOH Masanobu wrote: This patch worked. if_addrflags6's error messages disappeared. :) Before this patch, Aug 18 01:00:58 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 01:30:59 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 02:01:01 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 02:31:03 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 03:01:04 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 03:31:05 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 04:01:06 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 04:31:08 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 05:01:09 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 05:31:11 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 06:01:11 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 06:31:12 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 07:01:14 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 07:31:15 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 08:01:16 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument Aug 18 08:31:16 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument This error message appeared ever 30 minutes, but it also disappeared with this patch. That's avoiding the broken IP_PKTINFO implementation in NetBSD-7 - can't use it to send. Roy
Re: if_addrflags6: Can't assign requested address
On 2018/08/18 2:45, Roy Marples wrote: > On 17/08/2018 10:08, Roy Marples wrote: >> On 17/08/2018 09:04, Masanobu SAITOH wrote: wm2: carrier lost wm2: executing `/libexec/dhcpcd-run-hooks' NOCARRIER wm2: deleting address fe80::1392:4012:56d8:a7a2 wm2: if_addrflags6: Can't assign requested address wm2: if_addrflags6: Can't assign requested address wm2: if_addrflags6: Can't assign requested address wm2: if_addrflags6: Can't assign requested address wm2: carrier acquired wm2: executing `/libexec/dhcpcd-run-hooks' CARRIER >> >> This helps. >> I never saw this because on NetBSD-8, we have addrflags available in >> ifa_msghdr when sent over route(4). This does not exist on NetBSD-7 so we >> need to make an ioctl per address to work out the flags. Sadly, this is racy >> and this is what happens: >> >> Something adds an address. >> Kernel annnounces new address to route(4). >> Something deletes this address. >> Kernel announces the address deleted to route(4). >> >> dhcpcd reads the address added message from route(4) *after* the address has >> been deleted from the kernel. Because dhcpcd needs the address flags at this >> point, an ioctl is made to the deleted address and boom, error. >> >> Luckily dhcpcd handles it correctly and it's just noise. >> Please test the attached patch to silence it. >> If you can verify it works, let me know and I'll push a new version out. > > Since then I've discovered two more critical issues with dhcpcd-7 on NetBSD-7. > 1) Broken IP_PKTINFO implementation > 2) Invalid RTA_BRD in RTM_NEWADDR messages for new addresses > Both of these have already been fixed in -8 and -current and neither looks > suitable for a pullup and dhcpcd needs a workaround for both anyway. > > A better patch attached and I'll hopefully get this pushed out over the > weekend. > > Roy This patch worked. if_addrflags6's error messages disappeared. Before this patch, > Aug 18 01:00:58 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 01:30:59 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 02:01:01 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 02:31:03 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 03:01:04 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 03:31:05 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 04:01:06 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 04:31:08 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 05:01:09 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 05:31:11 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 06:01:11 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 06:31:12 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 07:01:14 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 07:31:15 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 08:01:16 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument > Aug 18 08:31:16 amd64-n7 dhcpcd[250]: wm1: dhcp_sendudp: Invalid argument This error message appeared ever 30 minutes, but it also disappeared with this patch. Thanks. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: Redoing the code in /bin/sh to handle the issues in PR bin/48875
Date:Fri, 17 Aug 2018 11:37:18 -0500
From:"J. Lewis Muir"
Message-ID: <20180817163717.ga21...@tuna.imca.aps.anl.gov>
| I think this sentence would read better if it used the same verb tense
Thanks, that is the kind of improvement I was looking for (since I don't
often even think of such issues...) and I will change it as you suggest.
| When I first read this, I didn't even know a command inside a "$()" could be
| terminated with an "&" to cause it to execute in the background in a
| sub-shell.
Any shell code can go in a command substitution, as it can almost anywhere
else that any commands are permitted -- people are sometiimes surprised when
they see, for the first time, a "while" statement, where the whole (long) loop
is in
the "test" part of the while, and the body of the loop contains nothing at all,
or
an "if" statement, where the condition is some other compound command, like
a while or until loop, or a case statement - but there are often advantages to
writing the script that way.
| I suggest including an example somewhere in the paragraph
| since it won't be read in the context of the PR.
On that second line (here), no, of course, the PR context if just
for this e-mail discussion.
[...]
| Lastly, I'm wondering if it would be helpful to include a statement on
| best-practice or a good idiom here.
Here (for both of the above suggestions) I was really hoping for ways to mak
there be less added text, rather than more, but I can see your point.
Perhaps both of those could be handled if this (even bigger) extra text was to
be added after (the corrected version of) what I sent before...
[ Aside: Note that this extra example is about as long as the (too long) text
I sent in the previous message - both before and after the correction you
suggested - and the original (retained though slightly modified) text about
command substitution, combined!
]
For example, assuming a script were to contain the following code (which
could be done better other ways, attempting this kind of trickery is not
recommended):
if [ "$( printf "Ready? " >&2; read ans; printf "${ans}";
{ sleep 120 >/dev/null && kill $$ >/dev/null 2>&1; }& )" = go ]
then
printf Working...
# more code
fi
the "Working..." output will not be printed, and code that follows will
never be executed. Nor will anything later in the script (unless SIGTERM
is trapped or ignored).
The intent is to prompt the user, wait for the user to answer, then if
the answer was "go" do the appropriate work, but set a 2 minute time
limit on completing that work. If the work is not done by then, kill the
shell doing it.
It will usually not work as written, as while the 2 minute `sleep' has
its standard output redirected, as does the `kill' that follows (which
also redirects standard error, so the user would not see an error if the
work were completed and there was no parent process left to kill); the
sub-shell waiting for the `sleep' to finish successfully, so it can start
the `kill', does not. It waits, with standard output still open, for the
2 minutes until the sleep is done, even though the kill is not going to
need that file descriptor, and there is nothing else which could. The
command substitution does not complete until after the kill has executed
and the background sub-shell finishes - at which time the shell running
it is presumably dead.
Rewriting the background sub-shell part of that as
{ sleep 120 && kill $$ 2>&1; } >/dev/null &
would allow this sh to perform as expected, but that is not guaranteed,
not all shells would behave as planned. It is advised to avoid starting
background processes from within a command substitution.
Does this actually help, or is all this text just making it less likely that
the average script writer will ever read any of it?
Of course, if we want to retain this new example text, or something like it,
then help improving it would be appreciated as well.
kre
Re: if_addrflags6: Can't assign requested address
On 17/08/2018 10:08, Roy Marples wrote:
On 17/08/2018 09:04, Masanobu SAITOH wrote:
wm2: carrier lost
wm2: executing `/libexec/dhcpcd-run-hooks' NOCARRIER
wm2: deleting address fe80::1392:4012:56d8:a7a2
wm2: if_addrflags6: Can't assign requested address
wm2: if_addrflags6: Can't assign requested address
wm2: if_addrflags6: Can't assign requested address
wm2: if_addrflags6: Can't assign requested address
wm2: carrier acquired
wm2: executing `/libexec/dhcpcd-run-hooks' CARRIER
This helps.
I never saw this because on NetBSD-8, we have addrflags available in
ifa_msghdr when sent over route(4). This does not exist on NetBSD-7 so
we need to make an ioctl per address to work out the flags. Sadly, this
is racy and this is what happens:
Something adds an address.
Kernel annnounces new address to route(4).
Something deletes this address.
Kernel announces the address deleted to route(4).
dhcpcd reads the address added message from route(4) *after* the address
has been deleted from the kernel. Because dhcpcd needs the address flags
at this point, an ioctl is made to the deleted address and boom, error.
Luckily dhcpcd handles it correctly and it's just noise.
Please test the attached patch to silence it.
If you can verify it works, let me know and I'll push a new version out.
Since then I've discovered two more critical issues with dhcpcd-7 on
NetBSD-7.
1) Broken IP_PKTINFO implementation
2) Invalid RTA_BRD in RTM_NEWADDR messages for new addresses
Both of these have already been fixed in -8 and -current and neither
looks suitable for a pullup and dhcpcd needs a workaround for both anyway.
A better patch attached and I'll hopefully get this pushed out over the
weekend.
Roy
diff --git a/src/dhcp.c b/src/dhcp.c
index 7a6749d4..1e9fe186 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -86,6 +86,11 @@
#define IPDEFTTL 64 /* RFC1340 */
#endif
+/* NetBSD-7 has an incomplete IP_PKTINFO implementation. */
+#if defined(__NetBSD_Version__) && __NetBSD_Version__ < 8
+#undef IP_PKTINFO
+#endif
+
/* Assert the correct structure size for on wire */
__CTASSERT(sizeof(struct ip) == 20);
__CTASSERT(sizeof(struct udphdr) == 8);
diff --git a/src/if-bsd.c b/src/if-bsd.c
index c3c95ba6..cdd959a6 100644
--- a/src/if-bsd.c
+++ b/src/if-bsd.c
@@ -1103,9 +1103,32 @@ if_ifa(struct dhcpcd_ctx *ctx, const struct ifa_msghdr
*ifam)
sin = (const void *)rti_info[RTAX_NETMASK];
mask.s_addr = sin != NULL && sin->sin_family == AF_INET ?
sin->sin_addr.s_addr : INADDR_ANY;
+
+#if defined(__NetBSD_Version__) && __NetBSD_Version__ < 8
+ /* NetBSD-7 and older send an invalid broadcast address.
+* So we need to query the actual address to get
+* the right one. */
+ {
+ struct in_aliasreq ifra;
+
+ memset(&ifra, 0, sizeof(ifra));
+ strlcpy(ifra.ifra_name, ifp->name,
+ sizeof(ifra.ifra_name));
+ ifra.ifra_addr.sin_family = AF_INET;
+ ifra.ifra_addr.sin_len = sizeof(ifra.ifra_addr);
+ ifra.ifra_addr.sin_addr = addr;
+ if (ioctl(ctx->pf_inet_fd, SIOCGIFALIAS, &ifra) == -1) {
+ if (errno != EADDRNOTAVAIL)
+ logerr("%s: SIOCGIFALIAS", __func__);
+ break;
+ }
+ bcast = ifra.ifra_broadaddr.sin_addr;
+ }
+#else
sin = (const void *)rti_info[RTAX_BRD];
bcast.s_addr = sin != NULL && sin->sin_family == AF_INET ?
sin->sin_addr.s_addr : INADDR_ANY;
+#endif
#if defined(__FreeBSD__) || defined(__DragonFly__)
/* FreeBSD sends RTM_DELADDR for each assigned address
@@ -1134,8 +1157,8 @@ if_ifa(struct dhcpcd_ctx *ctx, const struct ifa_msghdr
*ifam)
if (ifam->ifam_type == RTM_DELADDR)
addrflags = 0 ;
else if ((addrflags = if_addrflags(ifp, &addr, NULL)) == -1) {
- logerr("%s: if_addrflags: %s",
- ifp->name, inet_ntoa(addr));
+ if (errno != EADDRNOTAVAIL)
+ logerr("%s: if_addrflags", __func__);
break;
}
#endif
@@ -1160,7 +1183,8 @@ if_ifa(struct dhcpcd_ctx *ctx, const struct ifa_msghdr
*ifam)
if (ifam->ifam_type == RTM_DELADDR)
addrflags = 0;
else if ((addrflags = if_addrflags6(ifp, &addr6, NULL)) == -1) {
- logerr("%s: if_addrflags6", ifp->name);
+ if (errno != EADDRNOTAVAIL)
+ logerr("%s: if_addrflags6", __func__);
break;
}
#endif
diff --git a/src/if.c
Re: Redoing the code in /bin/sh to handle the issues in PR bin/48875
On 08/17, Robert Elz wrote: > I'd appreciate any suggestions for improvements, particularly ways > to convey the information included in a more succinct form. > > This is the (new) text I currently have ... > > Note that if a command substitution includes commands to be run in the > background, the sub-shell running those commands will only wait for them > to complete if an appropriate wait command is included in the command > list. However, the shell in which the result of the command substitution > will be used is waiting for both the sub-shell to exit, and for the file > descriptor that was initially standard output for the command > substitution sub-shell to be closed. Hi, Robert! I think this sentence would read better if it used the same verb tense as the preceding sentence. In this sentence, I think the verb tense of "is waiting" is present-continuous, but in the preceding sentence, I think the verb tense of "will wait" is simple-future. So, I would slightly reword this sentence to instead use the simple-future verb tense (along with removing the comma after "exit") as follows: However, the shell in which the result of the command substitution will be used will wait for both the sub-shell to exit and for the file descriptor that was initially standard output for the command substitution sub-shell to be closed. >While the exit of the sub-shell > closes its standard output, any background process left running may still > have that file descriptor open. This includes yet another sub-shell > which might have been (almost invisibly) created to wait for some other > command to complete, and even where that other command has had its > standard output redirected or closed, the waiting sub-shell may still > have it open. Thus there is no guarantee that the result of a command > substitution will be available in the shell which is to use it before all > of the commands started by the command substitution have completed, > though careful coding can often avoid delays beyond the termination of > the command substitution sub-shell. I suggest including an example somewhere in the paragraph since it won't be read in the context of the PR. The example could even be the one from the PR. When I first read this, I didn't even know a command inside a "$()" could be terminated with an "&" to cause it to execute in the background in a sub-shell. So, an example would help someone like me understand what this paragraph is talking about. Lastly, I'm wondering if it would be helpful to include a statement on best-practice or a good idiom here. To me, a command substitution that runs in the background seems weird and like something to avoid. Is there really a case where this is useful, or would it be reasonable to include a suggestion that it's best to avoid such a construct? Or if there is a case where this is useful, is this the best way to do it, and if not, what's a better way to do it? I'm thinking of something like the Caveats section of the printf(3) man page where it suggests the proper secure idiom for avoiding a format string vulnerability. But this is not a suggestion I'm confident about; I'm more just wondering about it. If it doesn't sound good, then forget it. Regards, Lewis
Redoing the code in /bin/sh to handle the issues in PR bin/48875
Some (or many) of you may be aware (and if not, please read the PR) that the code added in 2016 to deal with PR bin/48875 was never really correct - it just had not, until recently, caused anyone any problems so it had just been sitting there, doing its thing, and bothering no-one really, until just recently, when it actually did break a script. Thus I am going to (totally) revert the "fix" that was installed, and instead do something different (which would have eventually happened anyway). Rather than attempting to "fix" the PR (which I suspect is not really possible in the general case) the new code will simply reduce the chances of the delays which were the subject of the complaint in the PR from occurring. It is essentially a "performance enhancement" (which I have been resisting working on until all the known bugs are first fixed) which creates less sub-shells (the shell forks much less) almost all stolen from the FreeBSD shell (so the basic scheme has already had lots of testing there.) Because there are less sub-shells, there is less opportunity for one of them to be floating around holding a file descriptor open, which was the genesis of the 48875 problem. Part of this update will be to add some text to sh(1) to explain things a little better. The point of this e-mail is to seek assistance with getting that text into an acceptable form - while English is my native language, it is not the one I prefer to write (and I claim no proficiency at all). The following is my current proposal to add as a new paragraph, to the end of the current section in sh(1) under the heading "Command Substitution". This paragraph, is as long, or a bit longer than all that is currently there under that heading (which is going to get some minor wording changes as well, but they aren't a problem) - and so might be (!!?) a bit over the top. I'd appreciate any suggestions for improvements, particularly ways to convey the information included in a more succinct form. This is the (new) text I currently have ... Note that if a command substitution includes commands to be run in the background, the sub-shell running those commands will only wait for them to complete if an appropriate wait command is included in the command list. However, the shell in which the result of the command substitution will be used is waiting for both the sub-shell to exit, and for the file descriptor that was initially standard output for the command substitution sub-shell to be closed. While the exit of the sub-shell closes its standard output, any background process left running may still have that file descriptor open. This includes yet another sub-shell which might have been (almost invisibly) created to wait for some other command to complete, and even where that other command has had its standard output redirected or closed, the waiting sub-shell may still have it open. Thus there is no guarantee that the result of a command substitution will be available in the shell which is to use it before all of the commands started by the command substitution have completed, though careful coding can often avoid delays beyond the termination of the command substitution sub-shell. Suggestions? Thanks, kre ps: the intended new code runs the example in the PR without a delay, and passes all the sh ATF tests (including the even more difficult tests added to detect whether the PR is "fixed" or not). It also (as best I can tell) does not break pkg_chk -av ... I am still doing more tests though.
Re: if_addrflags6: Can't assign requested address
On 17/08/2018 09:04, Masanobu SAITOH wrote:
wm2: carrier lost
wm2: executing `/libexec/dhcpcd-run-hooks' NOCARRIER
wm2: deleting address fe80::1392:4012:56d8:a7a2
wm2: if_addrflags6: Can't assign requested address
wm2: if_addrflags6: Can't assign requested address
wm2: if_addrflags6: Can't assign requested address
wm2: if_addrflags6: Can't assign requested address
wm2: carrier acquired
wm2: executing `/libexec/dhcpcd-run-hooks' CARRIER
This helps.
I never saw this because on NetBSD-8, we have addrflags available in
ifa_msghdr when sent over route(4). This does not exist on NetBSD-7 so
we need to make an ioctl per address to work out the flags. Sadly, this
is racy and this is what happens:
Something adds an address.
Kernel annnounces new address to route(4).
Something deletes this address.
Kernel announces the address deleted to route(4).
dhcpcd reads the address added message from route(4) *after* the address
has been deleted from the kernel. Because dhcpcd needs the address flags
at this point, an ioctl is made to the deleted address and boom, error.
Luckily dhcpcd handles it correctly and it's just noise.
Please test the attached patch to silence it.
If you can verify it works, let me know and I'll push a new version out.
Thanks
Roy
diff --git a/src/if-bsd.c b/src/if-bsd.c
index c3c95ba6..c03e4f6d 100644
--- a/src/if-bsd.c
+++ b/src/if-bsd.c
@@ -1134,8 +1134,8 @@ if_ifa(struct dhcpcd_ctx *ctx, const struct ifa_msghdr
*ifam)
if (ifam->ifam_type == RTM_DELADDR)
addrflags = 0 ;
else if ((addrflags = if_addrflags(ifp, &addr, NULL)) == -1) {
- logerr("%s: if_addrflags: %s",
- ifp->name, inet_ntoa(addr));
+ if (errno != EADDRNOTAVAIL)
+ logerr("%s: if_addrflags", __func__);
break;
}
#endif
@@ -1160,7 +1160,8 @@ if_ifa(struct dhcpcd_ctx *ctx, const struct ifa_msghdr
*ifam)
if (ifam->ifam_type == RTM_DELADDR)
addrflags = 0;
else if ((addrflags = if_addrflags6(ifp, &addr6, NULL)) == -1) {
- logerr("%s: if_addrflags6", ifp->name);
+ if (errno != EADDRNOTAVAIL)
+ logerr("%s: if_addrflags6", __func__);
break;
}
#endif
diff --git a/src/if.c b/src/if.c
index eaebefa5..c1c81eb6 100644
--- a/src/if.c
+++ b/src/if.c
@@ -240,7 +240,7 @@ if_learnaddrs(struct dhcpcd_ctx *ctx, struct if_head *ifs,
addrflags = if_addrflags(ifp, &addr->sin_addr,
ifa->ifa_name);
if (addrflags == -1) {
- if (errno != EEXIST)
+ if (errno != EEXIST && errno != EADDRNOTAVAIL)
logerr("%s: if_addrflags: %s",
__func__,
inet_ntoa(addr->sin_addr));
@@ -266,7 +266,7 @@ if_learnaddrs(struct dhcpcd_ctx *ctx, struct if_head *ifs,
addrflags = if_addrflags6(ifp, &sin6->sin6_addr,
ifa->ifa_name);
if (addrflags == -1) {
- if (errno != EEXIST)
+ if (errno != EEXIST || errno == EADDRNOTAVAIL)
logerr("%s: if_addrflags6", __func__);
continue;
}
Re: if_addrflags6: Can't assign requested address
On 2018/08/12 0:11, Roy Marples wrote: Hi On 08/08/2018 03:13, Masanobu SAITOH wrote: Hi. While testing netbsd-7, I've noticed dhcpcd put the following message: Configuring network interfaces: wm0wm0: if_addrflags6: Can't assign requested address wm0: if_addrflags6: Can't assign requested address wm0: if_addrflags6: Can't assign requested address wm0: if_addrflags6: Can't assign requested address Can we ignore this message, or is it a real problem? /etc/dhcpcd.conf is the default. I just got back and cannot replicate this issue with the latest netbsd-7 sources which ship with dhcpcd-7.0.7. I use a XEN DOMU for testing. Can you provide more information please? In /etc/rc.conf: ip6mode=autohost ifconfig_wm2=dhcp dhcpcd_flags="-d" No /etc/ifconfig.wm2. When boot: Starting network. Hostname: amd64-n7.execsw.org IPv6 mode: autoconfigured host Configuring network interfaces: wm2dhcpcd-7.0.7 starting wm2: executing `/libexec/dhcpcd-run-hooks' PREINIT wm2: executing `/libexec/dhcpcd-run-hooks' CARRIER DUID 00:01:00:01:1c:4b:d9:02:00:26:55:57:20:ac wm2: IAID 90:82:9b:a4 wm2: adding address fe80::1392:4012:56d8:a7a2 wm2: pltime infinity, vltime infinity wm2: delaying IPv6 router solicitation for 0.5 seconds wm2: delaying IPv4 for 0.9 seconds wm2: carrier lost wm2: executing `/libexec/dhcpcd-run-hooks' NOCARRIER wm2: deleting address fe80::1392:4012:56d8:a7a2 wm2: carrier acquired wm2: executing `/libexec/dhcpcd-run-hooks' CARRIER wm2: IAID 90:82:9b:a4 wm2: adding address fe80::1392:4012:56d8:a7a2 wm2: pltime infinity, vltime infinity wm2: delaying IPv6 router solicitation for 0.9 seconds wm2: delaying IPv4 for 0.2 seconds wm2: carrier lost wm2: executing `/libexec/dhcpcd-run-hooks' NOCARRIER wm2: deleting address fe80::1392:4012:56d8:a7a2 wm2: if_addrflags6: Can't assign requested address wm2: if_addrflags6: Can't assign requested address wm2: if_addrflags6: Can't assign requested address wm2: if_addrflags6: Can't assign requested address wm2: carrier acquired wm2: executing `/libexec/dhcpcd-run-hooks' CARRIER wm2: IAID 90:82:9b:a4 wm2: adding address fe80::1392:4012:56d8:a7a2 wm2: pltime infinity, vltime infinity wm2: delaying IPv6 router solicitation for 0.4 seconds wm2: delaying IPv4 for 0.2 seconds wm2: reading lease `/var/db/dhcpcd/wm2.lease' wm2: rebinding lease of 192.168.0.178 wm2: sending REQUEST (xid 0x63705096), next in 4.4 seconds wm2: acknowledged 192.168.0.178 from 192.168.0.2 wm2: probing address 192.168.0.178/24 wm2: probing for 192.168.0.178 wm2: ARP probing 192.168.0.178 (1 of 3), next in 1.6 seconds wm2: soliciting an IPv6 router wm2: delaying Router Solicitation for LL address wm2: sending Router Solicitation wm2: ARP probing 192.168.0.178 (2 of 3), next in 1.8 seconds wm2: ARP probing 192.168.0.178 (3 of 3), next in 2.0 seconds wm2: sending Router Solicitation wm2: DAD completed for 192.168.0.178 wm2: leased 192.168.0.178 for 43200 seconds wm2: renew in 21600 seconds, rebind in 37800 seconds wm2: writing lease `/var/db/dhcpcd/wm2.lease' wm2: adding IP address 192.168.0.178/24 broadcast 192.168.0.255 wm2: adding route to 192.168.0.0/24 wm2: adding default route via 192.168.0.2 wm2: ARP announcing 192.168.0.178 (1 of 2), next in 2.0 seconds wm2: executing `/libexec/dhcpcd-run-hooks' BOUND forking to background forked to background, child pid 250 . Adding interface aliases:. Waiting for DAD completion for statically configured addresses... Does this log help for you? Roy -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2018.08.17.04.59.34 kre src/sys/arch/i386/stand/efiboot/panic.c,v 1.5 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2018.08.html#2018.08.17.04.59.34
