ifconfig not waiting for DAD completion

[Anthony Mallet]

When my wm(4) interface goes from down to up, it first enters a 'detached'
state for 1s or so, then the carrier is detected and the interface goes to the
ipv6 'tentative' state.

The detached state is long enough for ifconfig -w in /etc/rc.d/network to not
wait at all for DAD (the interface is still 'detached' when ifconfig -w runs).

This then leads to unexpected delays (~30s) in e.g. /etc/rc.d/mountall with an
NFS filesystem. (The machine is in ip6mode=host).

I tried the following quick patch to ifconfig(8) so that ifconfig -w waits for
DAD completion only once DAD has started. Does this look like the proper fix?

Index: sbin/ifconfig/af_inet6.c
===================================================================
RCS file: /cvsroot/src/sbin/ifconfig/af_inet6.c,v
retrieving revision 1.33
diff -u -r1.33 af_inet6.c
--- sbin/ifconfig/af_inet6.c 12 May 2015 14:05:29 -0000 1.33
+++ sbin/ifconfig/af_inet6.c 27 Nov 2015 00:05:46 -0000
@@ -489,7 +489,7 @@
ifr.ifr_addr = *(struct sockaddr_in6 *)ifa->ifa_addr;
if (prog_ioctl(s, SIOCGIFAFLAG_IN6, &ifr) == -1)
err(EXIT_FAILURE, "SIOCGIFAFLAG_IN6");
- return ifr.ifr_ifru.ifru_flags6 & IN6_IFF_TENTATIVE ? true : false;
+ return ifr.ifr_ifru.ifru_flags6 & (IN6_IFF_TENTATIVE|IN6_IFF_DETACHED) ? true : false;
}

static void

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Hi

Post by Anthony Mallet
When my wm(4) interface goes from down to up, it first enters a 'detached'
state for 1s or so, then the carrier is detected and the interface goes to the
ipv6 'tentative' state.

I believe this behaviour is true for all interfaces, it's not specific
to wm(4).

The best way of fixing this is to reduce this window to zero because
it's a small lie - kernel is telling userland the link is down when it's
really up.
I don't know how to start doing that though .... I suspect each driver
would need to be touched somewhere.

Post by Anthony Mallet
The detached state is long enough for ifconfig -w in /etc/rc.d/network to not
wait at all for DAD (the interface is still 'detached' when ifconfig -w runs).
This then leads to unexpected delays (~30s) in e.g. /etc/rc.d/mountall with an
NFS filesystem. (The machine is in ip6mode=host).
I tried the following quick patch to ifconfig(8) so that ifconfig -w waits for
DAD completion only once DAD has started. Does this look like the proper fix?
Index: sbin/ifconfig/af_inet6.c
===================================================================
RCS file: /cvsroot/src/sbin/ifconfig/af_inet6.c,v
retrieving revision 1.33
diff -u -r1.33 af_inet6.c
--- sbin/ifconfig/af_inet6.c 12 May 2015 14:05:29 -0000 1.33
+++ sbin/ifconfig/af_inet6.c 27 Nov 2015 00:05:46 -0000
@@ -489,7 +489,7 @@
ifr.ifr_addr = *(struct sockaddr_in6 *)ifa->ifa_addr;
if (prog_ioctl(s, SIOCGIFAFLAG_IN6, &ifr) == -1)
err(EXIT_FAILURE, "SIOCGIFAFLAG_IN6");
- return ifr.ifr_ifru.ifru_flags6 & IN6_IFF_TENTATIVE ? true : false;
+ return ifr.ifr_ifru.ifru_flags6 & (IN6_IFF_TENTATIVE|IN6_IFF_DETACHED) ? true : false;
}
static void

Any fix like this would also be needed in af_inet.c as IPv4 has similar
flags.
But if we do this then I think that ifconfig.c:wait_dad_exec() needs to
test the interface flags for IFF_UP as well.

Not that it helps because when you add an address, the interface is
brought up right away.

I avoided detached originally because I didn't want to wait for a
configured interface without an attached cable because that would just
timeout needlessly. But is that actually desireable behaviour?
This also affects wireless interfaces, so it's not entirely optimal either.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Roy Marples

Post by Anthony Mallet
When my wm(4) interface goes from down to up, it first enters a 'detached'
state for 1s or so, then the carrier is detected and the interface goes to the
ipv6 'tentative' state.

I believe this behaviour is true for all interfaces, it's not specific
to wm(4).
The best way of fixing this is to reduce this window to zero because
it's a small lie - kernel is telling userland the link is down when it's
really up.
I don't know how to start doing that though .... I suspect each driver
would need to be touched somewhere.

The attached patch should fix it for wm(4), but I won't have a chance to
actually test it fully until the weekend.

Can you test it to see if it fixes your issue?

Thanks

Roy

[Anthony Mallet]

On Friday, at 10:02, Roy Marples wrote:
| The attached patch should fix it for wm(4), but I won't have a chance to
| actually test it fully until the weekend.
|
| Can you test it to see if it fixes your issue?

I also won't have a chance to give it a try before this evening, but I'll keep
you posted.
Thanks!

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Anthony Mallet]

On Friday, at 10:02, Roy Marples wrote:
| The attached patch should fix it for wm(4), but I won't have a chance to
| actually test it fully until the weekend.
|
| Can you test it to see if it fixes your issue?

The results are a bit surprising to me :
- wm(4) still starts in the 'detached' state after becoming up.
- `ifconfig -w` consequently does not wait at all.

The big difference is that mount_nfs does not report the
"rpcbind to nfs on server: RPC: Port mapper failure - RPC: Unable to send"
error anymore, and merely waits a few (5 or so) seconds that the interface goes
through "detached" -> "tentative" -> "". (instead of the ~30s delay without
your patch).

So all in all your patch does the job, but I don't fully get why. And I'm still
a bit frustrated that ifconfig -w does nothing :)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Anthony Mallet
| The attached patch should fix it for wm(4), but I won't have a chance to
| actually test it fully until the weekend.
|
| Can you test it to see if it fixes your issue?
- wm(4) still starts in the 'detached' state after becoming up.
- `ifconfig -w` consequently does not wait at all.

That is surprising.
Attached is a new patch with one extra line to ensure sc_flags is set
before calling the tick function, but I'm not sure if that will help
any.

Let me know!

Post by Anthony Mallet
The big difference is that mount_nfs does not report the
"rpcbind to nfs on server: RPC: Port mapper failure - RPC: Unable to send"
error anymore, and merely waits a few (5 or so) seconds that the interface goes
through "detached" -> "tentative" -> "". (instead of the ~30s delay without
your patch).

Well, the patch is probably causing the interface to notify the link
being up just a second faster.
We could also try calling the tick function a second time in wm_init to
see if it just needed to be tickled.

Post by Anthony Mallet
So all in all your patch does the job, but I don't fully get why. And I'm still
a bit frustrated that ifconfig -w does nothing :)

Yes, maybe ifconfig -w *should* do something.
I was trying to avoid waiting for interfaces that really have no carrier
(ie a cable plugged in), but as you point out we don't want the test to
pass if it takes a few seconds for the interface to realise it has a
carrier. This is doubly true for wireless and I don't know how a host AP
interface would behave here.

Does anyone have any thoughts on if -w should wait for detached as well,
or if we should roll that into a new flag (maybe -W)? And on how to
choose which one in rc.d/network?

Roy

[Roy Marples]

Post by Anthony Mallet
If ifconfig -w is to wait for detached as well, maybe it could take an
interface name (like -s), e.g. `ifconfig -w 4 wm0` and a new variable added in
rc.conf, e.g. waitdad_interfaces="wm0 wm1". Or just waitdad=YES/NO and using
whatever is in net_interfaces or in the auto_ifconfig computed list.
Another approach could be `ifconfig wm0 ... waitdad 4` so that this can be
tuned in $ifconfig_xxN. But this looses the parallelism if one has several
interfaces.

Here's a patch which adds the -W flag to ifconfig(8) which will wait for
N seconds for the detached flag to clear.
This does not extend the -w flag option duration.

The default has been set to -w 10 -W 2.
Please test it, as we may need to increase them - they are currently low
to ensure as fast as a boot as possible.

Roy

[Anthony Mallet]

On Sunday 20 Dec 2015, at 17:17, Roy Marples wrote:
| Here's a patch which adds the -W flag to ifconfig(8) which will wait
| for N seconds for the detached flag to clear. This does not extend
| the -w flag option duration.
|
| The default has been set to -w 10 -W 2. Please test it, as we may
| need to increase them - they are currently low to ensure as fast as
| a boot as possible.

Your patch does the job nicely! Thanks!
There is a typo in the etc/default/rc.conf comment, see attachment.

With my Intel i82541PI 1000BASE-T Ethernet (rev. 0x05), the
required -W time is closer to 4-5 secs. I set it to 10 in rc.conf
without bothering too much finding the smallest number, as this
machine is supposed to be on the network anyway and has a single
interface.

The time required for DAD however is much shorter, about 1 second.

What about the sysctl net.inet{,6}.ip{,6}.dad_count. Is it still
useful for anything?

[Roy Marples]

Post by Anthony Mallet
| Here's a patch which adds the -W flag to ifconfig(8) which will wait
| for N seconds for the detached flag to clear. This does not extend
| the -w flag option duration.
|
| The default has been set to -w 10 -W 2. Please test it, as we may
| need to increase them - they are currently low to ensure as fast as
| a boot as possible.
Your patch does the job nicely! Thanks!
There is a typo in the etc/default/rc.conf comment, see attachment.
With my Intel i82541PI 1000BASE-T Ethernet (rev. 0x05), the
required -W time is closer to 4-5 secs. I set it to 10 in rc.conf
without bothering too much finding the smallest number, as this
machine is supposed to be on the network anyway and has a single
interface.

This is now committed.
I made two other changes - testing for IFF_UP in the detached case and
changing the defaults to -w 15 -W 5 which should now be large enough (5
seconds carrier, a futher 10 seconds for flags to clear).

Post by Anthony Mallet
The time required for DAD however is much shorter, about 1 second.
What about the sysctl net.inet{,6}.ip{,6}.dad_count. Is it still
useful for anything?

The sysctls are used by the kernel only now.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Anthony Mallet]

On Tuesday, at 16:06, Roy Marples wrote:
| On 2015-11-27 22:37, Anthony Mallet wrote:
| > The results are a bit surprising to me :
| > - wm(4) still starts in the 'detached' state after becoming up.
| > - `ifconfig -w` consequently does not wait at all.
|
| That is surprising.
| Attached is a new patch with one extra line to ensure sc_flags is set
| before calling the tick function, but I'm not sure if that will help
| any.
|
| Let me know!

No, this does not help.

From what I can observe, it takes 2-3 seconds for the interface to realise that
it has a link. So it makes sense that calling wm_tick() one second earlier or
later does not help.

| We could also try calling the tick function a second time in wm_init to
| see if it just needed to be tickled.

I tried that (calling wm_tick() twice), but this did not help either.

| Yes, maybe ifconfig -w *should* do something.
| I was trying to avoid waiting for interfaces that really have no carrier
| (ie a cable plugged in), but as you point out we don't want the test to
| pass if it takes a few seconds for the interface to realise it has a
| carrier. This is doubly true for wireless and I don't know how a host AP
| interface would behave here.
|
| Does anyone have any thoughts on if -w should wait for detached as well,
| or if we should roll that into a new flag (maybe -W)? And on how to
| choose which one in rc.d/network?

If ifconfig -w is to wait for detached as well, maybe it could take an
interface name (like -s), e.g. `ifconfig -w 4 wm0` and a new variable added in
rc.conf, e.g. waitdad_interfaces="wm0 wm1". Or just waitdad=YES/NO and using
whatever is in net_interfaces or in the auto_ifconfig computed list.

Another approach could be `ifconfig wm0 ... waitdad 4` so that this can be
tuned in $ifconfig_xxN. But this looses the parallelism if one has several
interfaces.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de