The following reply was made to PR bin/51622; it has been noted by GNATS.
From: Timshel Knoll-Miller <timshel%fluentdevelopment.com.au@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc:
Subject: Re: bin/51622: npf startup failure when using dhcpcd inet4 and inet6
Date: Sun, 13 Nov 2016 17:57:44 +1100
--94eb2c09538e8d35ca0541293d61
Content-Type: multipart/alternative; boundary=94eb2c09538e8d35c10541293d5f
--94eb2c09538e8d35c10541293d5f
Content-Type: text/plain; charset=UTF-8
I've discovered a few more details since I logged this.
It seems that this NPF failure only occurs when dhcpcd(8) is acquiring
addresses for more than one interface.
Contrary to what I've written before, when dhcpcd(8) is bound to a SINGLE
interface, and "--waitip 4 --waitip 6" arguments are given, it does seem to
wait until both IPv4 and IPv6 addresses have been assigned before forking
to the background.
However, when used with multiple interfaces, dhcpcd will fork after ANY one
interface gets an IPv4 address, and ANY one interface gets an IPv6 address.
NPF then gets enabled, and if npf.conf includes an inet4() or inet6() call
for an interface that doesn't have any addresses of that type, it fails as
described in my original PR.
The servers I've been experiencing this issue with have two interfaces - an
external-facing one on a public IP, and an internal one on a private IP.
Hence why this was occuring for me. Even though I only had my npf.conf
looking for addresses on my public interface, I was passing "-qM vioif0
vioif1" and dhcpcd was forking to the background before it had assigned an
IPv4 address to vioif0. It seems the DHCP server on vioif1 is a bit quicker
as this was happening pretty consistently.
I found you can work around this by running dhcpcd separately for each
interface. Adding "!dhcpcd -q --waitip 4 --waitip 6 $int" to each
/etc/ifconfig.<interface> and setting dhcpcd=NO in /etc/rc.conf does work.
However it also makes the startup take quite a lot longer, as it has to run
DHCP requests separately for each interface, rather than in parallel. And
dhcpcd can't really be used in master mode in this circumstance.
I've looked through the NetBSD dhcpcd commits to -current and noticed that
there a fix to this issue was committed in May 2015 when dhcpcd was updated
to version 6.9.0. (see the new dhcpcd_ifipwaited() function and changes to
dhcpcd_ipwaited() in `cvs diff -r1.24 -r1.25
external/bsd/dhcpcd/dist/dhcpcd.c').
I've backported the relevant changes from dhcpcd 6.9.0 and attached a
patch. I've built 7.0_STABLE and 7.0.2_PATCH releases locally with this
patch applied. With "dhcpcd_args="-qM --waitip 4 --waitip6 vioif0 vioif1"
in my /etc/rc.conf, npf successfully enables on boot.
While this isn't a show-stopper, it significantly limits npf's usefulness
on NetBSD 7 and would be good to see this issue fixed on the netbsd-7
branch prior to 7.1 please.
Cheers,
Timshel
--94eb2c09538e8d35c10541293d5f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I've discovered a few more details since I logged this=
.<div><br></div><div>It seems that this NPF failure only occurs when dhcpcd=
(8) is acquiring addresses for more than one interface.</div><div><br></div=
><div>Contrary to what I've written before, when dhcpcd(8) is bound to =
a SINGLE interface, and "--waitip 4 --waitip 6" arguments are giv=
en, it does seem to wait until both IPv4 and IPv6 addresses have been assig=
ned before forking to the background.</div><div><br></div><div>However, whe=
n used with multiple interfaces, dhcpcd will fork after ANY one interface g=
ets an IPv4 address, and ANY one interface gets an IPv6 address. NPF then g=
ets enabled, and if npf.conf includes an inet4() or inet6() call for an int=
erface that doesn't have any addresses of that type, it fails as descri=
bed in my original PR.</div><div><div><br class=3D"gmail-Apple-interchange-=
newline">The servers I've been experiencing this issue with have two in=
terfaces - an external-facing one on a public IP, and an internal one on a =
private IP. Hence why this was occuring for me. Even though I only had my n=
pf.conf looking for addresses on my public interface, I was passing "-=
qM vioif0 vioif1" and dhcpcd was forking to the background before it h=
ad assigned an IPv4 address to vioif0. It seems the DHCP server on vioif1 i=
s a bit quicker as this was happening pretty consistently.</div></div><div>=
<br></div><div>I found you can work around this by running dhcpcd separatel=
y for each interface. Adding "!dhcpcd -q --waitip 4 --waitip 6 $int&qu=
ot; to each /etc/ifconfig.<interface> and setting dhcpcd=3DNO in /etc=
/rc.conf does work. However it also makes the startup take quite a lot long=
er, as it has to run DHCP requests separately for each interface, rather th=
an in parallel. And dhcpcd can't really be used in master mode in this =
circumstance.</div><div><br></div><div>I've looked through the NetBSD d=
hcpcd commits to -current and noticed that there a fix to this issue was co=
mmitted in May 2015 when dhcpcd was updated to version 6.9.0. (see the new =
dhcpcd_ifipwaited() function and changes to dhcpcd_ipwaited() in =C2=A0`cvs=
diff -r1.24 -r1.25 external/bsd/dhcpcd/dist/dhcpcd.c').</div><div><br>=
</div><div>I've backported the relevant changes from dhcpcd 6.9.0 and a=
ttached a patch. I've built 7.0_STABLE and 7.0.2_PATCH releases locally=
with this patch applied. With "dhcpcd_args=3D"-qM --waitip 4 --w=
aitip6 vioif0 vioif1" in my /etc/rc.conf, npf successfully enables on =
boot.<br></div><div><br></div><div>While this isn't a show-stopper, it =
significantly limits npf's usefulness on NetBSD 7 and would be good to =
see this issue fixed on the netbsd-7 branch prior to 7.1 please.=C2=A0<br><=
/div><div><div class=3D"gmail_extra"><div><div class=3D"gmail_signature"><d=
iv dir=3D"ltr">
<div dir=3D"ltr">
<p style=3D"font-family:verdana,sans-serif">Cheers,</p><p style=3D"font=
-family:verdana,sans-serif">Timshel</p></div></div></div></div></div></div>=
</div>
--94eb2c09538e8d35c10541293d5f--
--94eb2c09538e8d35ca0541293d61
Content-Type: application/octet-stream;
name="netbsd-7-dhcpcd-wait-all-ifs.patch"
Content-Disposition: attachment;
filename="netbsd-7-dhcpcd-wait-all-ifs.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_ivg9w23i0
ZGlmZiAtLWdpdCBhL2V4dGVybmFsL2JzZC9kaGNwY2QvZGlzdC9kaGNwY2QuYyBiL2V4dGVybmFs
L2JzZC9kaGNwY2QvZGlzdC9kaGNwY2QuYwppbmRleCAwYjg1YWExLi5hZjU0MDMxIDEwMDY0NAot
LS0gYS9leHRlcm5hbC9ic2QvZGhjcGNkL2Rpc3QvZGhjcGNkLmMKKysrIGIvZXh0ZXJuYWwvYnNk
L2RoY3BjZC9kaXN0L2RoY3BjZC5jCkBAIC0yMTgsMjYgKzIxOCw1MCBAQCBkaGNwY2Rfb25ldXAo
c3RydWN0IGRoY3BjZF9jdHggKmN0eCkKIAlyZXR1cm4gMDsKIH0KIAotaW50Ci1kaGNwY2RfaXB3
YWl0ZWQoc3RydWN0IGRoY3BjZF9jdHggKmN0eCkKK3N0YXRpYyBpbnQKK2RoY3BjZF9pZmlwd2Fp
dGVkKHN0cnVjdCBpbnRlcmZhY2UgKmlmcCwgdW5zaWduZWQgbG9uZyBsb25nIG9wdHMpCiB7CiAK
LQlpZiAoY3R4LT5vcHRpb25zICYgREhDUENEX1dBSVRJUDQgJiYKLQkgICAgIWlwdjRfYWRkcmV4
aXN0cyhjdHgsIE5VTEwpKQorCWlmIChvcHRzICYgREhDUENEX1dBSVRJUDQgJiYgIWlwdjRfaWZh
ZGRyZXhpc3RzKGlmcCkpCiAJCXJldHVybiAwOwotCWlmIChjdHgtPm9wdGlvbnMgJiBESENQQ0Rf
V0FJVElQNiAmJgotCSAgICAhaXB2Nm5kX2ZpbmRhZGRyKGN0eCwgTlVMTCwgMCkgJiYKLQkgICAg
IWRoY3A2X2ZpbmRhZGRyKGN0eCwgTlVMTCwgMCkpCisJaWYgKG9wdHMgJiBESENQQ0RfV0FJVElQ
NiAmJiAhaXB2Nl9pZmZpbmRhZGRyKGlmcCwgTlVMTCkpCiAJCXJldHVybiAwOwotCWlmIChjdHgt
Pm9wdGlvbnMgJiBESENQQ0RfV0FJVElQICYmCi0JICAgICEoY3R4LT5vcHRpb25zICYgKERIQ1BD
RF9XQUlUSVA0IHwgREhDUENEX1dBSVRJUDYpKSAmJgotCSAgICAhaXB2NF9hZGRyZXhpc3RzKGN0
eCwgTlVMTCkgJiYKLQkgICAgIWlwdjZuZF9maW5kYWRkcihjdHgsIE5VTEwsIDApICYmCi0JICAg
ICFkaGNwNl9maW5kYWRkcihjdHgsIE5VTEwsIDApKQorCWlmIChvcHRzICYgREhDUENEX1dBSVRJ
UCAmJgorCSAgICAhKG9wdHMgJiAoREhDUENEX1dBSVRJUDQgfCBESENQQ0RfV0FJVElQNikpICYm
CisJICAgICFpcHY0X2lmYWRkcmV4aXN0cyhpZnApICYmCisJICAgICFpcHY2X2lmZmluZGFkZHIo
aWZwLCBOVUxMKSkKIAkJcmV0dXJuIDA7CiAJcmV0dXJuIDE7CiB9CiAKK3N0YXRpYyBpbnQKK2Ro
Y3BjZF9pcHdhaXRlZChzdHJ1Y3QgZGhjcGNkX2N0eCAqY3R4KQoreworCXN0cnVjdCBpbnRlcmZh
Y2UgKmlmcDsKKworCVRBSUxRX0ZPUkVBQ0goaWZwLCBjdHgtPmlmYWNlcywgbmV4dCkgeworCQlp
ZiAoaWZwLT5vcHRpb25zLT5vcHRpb25zICYgREhDUENEX1dBSVRPUFRTKSB7CisJCQlpZiAoIWRo
Y3BjZF9pZmlwd2FpdGVkKGlmcCwgaWZwLT5vcHRpb25zLT5vcHRpb25zKSkgeworCQkJCXN5c2xv
ZyhMT0dfREVCVUcsCisJCQkJICAgICIlczogd2FpdGluZyBmb3IgYW4gaXAgYWRkcmVzcyIsCisJ
CQkJICAgIGlmcC0+bmFtZSk7CisJCQkJcmV0dXJuIDA7CisJCQl9CisJCX0KKwl9CisKKwlpZiAo
IShjdHgtPm9wdGlvbnMgJiBESENQQ0RfV0FJVE9QVFMpKQorCQlyZXR1cm4gMTsKKworCVRBSUxR
X0ZPUkVBQ0goaWZwLCBjdHgtPmlmYWNlcywgbmV4dCkgeworCQlpZiAoZGhjcGNkX2lmaXB3YWl0
ZWQoaWZwLCBjdHgtPm9wdGlvbnMpKQorCQkJcmV0dXJuIDE7CisJfQorCisJc3lzbG9nKExPR19E
RUJVRywgIndhaXRpbmcgZm9yIGFuIGlwIGFkZHJlc3MiKTsKKwlyZXR1cm4gMDsKK30KKwogLyog
UmV0dXJucyB0aGUgcGlkIG9mIHRoZSBjaGlsZCwgb3RoZXJ3aXNlIDAuICovCiBwaWRfdAogZGhj
cGNkX2RhZW1vbmlzZShzdHJ1Y3QgZGhjcGNkX2N0eCAqY3R4KQpkaWZmIC0tZ2l0IGEvZXh0ZXJu
YWwvYnNkL2RoY3BjZC9kaXN0L2RoY3BjZC5oIGIvZXh0ZXJuYWwvYnNkL2RoY3BjZC9kaXN0L2Ro
Y3BjZC5oCmluZGV4IGU4MmViYTEuLjk2MmVhZWIgMTAwNjQ0Ci0tLSBhL2V4dGVybmFsL2JzZC9k
aGNwY2QvZGlzdC9kaGNwY2QuaAorKysgYi9leHRlcm5hbC9ic2QvZGhjcGNkL2Rpc3QvZGhjcGNk
LmgKQEAgLTM0LDYgKzM0LDEwIEBACiAjaW5jbHVkZSA8bmV0L2lmLmg+CiAKICNpbmNsdWRlICJj
b25maWcuaCIKKyNpZmRlZiBIQVZFX1NZU19RVUVVRV9ICisjaW5jbHVkZSA8c3lzL3F1ZXVlLmg+
CisjZW5kaWYKKwogI2luY2x1ZGUgImRlZnMuaCIKICNpbmNsdWRlICJjb250cm9sLmgiCiAjaW5j
bHVkZSAiaWYtb3B0aW9ucy5oIgpAQCAtMTU3LDcgKzE2MSw2IEBAIGV4dGVybiBjb25zdCBpbnQg
ZGhjcGNkX2hhbmRsZXNpZ3NbXTsKICNlbmRpZgogCiBpbnQgZGhjcGNkX29uZXVwKHN0cnVjdCBk
aGNwY2RfY3R4ICopOwotaW50IGRoY3BjZF9pcHdhaXRlZChzdHJ1Y3QgZGhjcGNkX2N0eCAqKTsK
IHBpZF90IGRoY3BjZF9kYWVtb25pc2Uoc3RydWN0IGRoY3BjZF9jdHggKik7CiAKIGludCBkaGNw
Y2RfaGFuZGxlYXJncyhzdHJ1Y3QgZGhjcGNkX2N0eCAqLCBzdHJ1Y3QgZmRfbGlzdCAqLCBpbnQs
IGNoYXIgKiopOwpkaWZmIC0tZ2l0IGEvZXh0ZXJuYWwvYnNkL2RoY3BjZC9kaXN0L2lmLW9wdGlv
bnMuaCBiL2V4dGVybmFsL2JzZC9kaGNwY2QvZGlzdC9pZi1vcHRpb25zLmgKaW5kZXggODY4MTg4
Zi4uYjQ1YWQ2NiAxMDA2NDQKLS0tIGEvZXh0ZXJuYWwvYnNkL2RoY3BjZC9kaXN0L2lmLW9wdGlv
bnMuaAorKysgYi9leHRlcm5hbC9ic2QvZGhjcGNkL2Rpc3QvaWYtb3B0aW9ucy5oCkBAIC0xMTAs
NiArMTEwLDggQEAKICNkZWZpbmUgREhDUENEX1BGWERMR01JWAkJKDFVTEwgPDwgNTMpCiAjZGVm
aW5lIERIQ1BDRF9JUFY2UkFfQVVUT0NPTkYJCSgxVUxMIDw8IDU0KQogCisjZGVmaW5lIERIQ1BD
RF9XQUlUT1BUUyAoREhDUENEX1dBSVRJUCB8IERIQ1BDRF9XQUlUSVA0IHwgREhDUENEX1dBSVRJ
UDYpCisKIGV4dGVybiBjb25zdCBzdHJ1Y3Qgb3B0aW9uIGNmX29wdGlvbnNbXTsKIAogc3RydWN0
IGlmX3NsYSB7CmRpZmYgLS1naXQgYS9leHRlcm5hbC9ic2QvZGhjcGNkL2Rpc3QvaXB2NC5jIGIv
ZXh0ZXJuYWwvYnNkL2RoY3BjZC9kaXN0L2lwdjQuYwppbmRleCBiYzUxYmExLi5mNTRiMTA0IDEw
MDY0NAotLS0gYS9leHRlcm5hbC9ic2QvZGhjcGNkL2Rpc3QvaXB2NC5jCisrKyBiL2V4dGVybmFs
L2JzZC9kaGNwY2QvZGlzdC9pcHY0LmMKQEAgLTE2MCw2ICsxNjAsMTUgQEAgaXB2NF9maW5kYWRk
cihzdHJ1Y3QgZGhjcGNkX2N0eCAqY3R4LCBjb25zdCBzdHJ1Y3QgaW5fYWRkciAqYWRkcikKIH0K
IAogaW50CitpcHY0X2lmYWRkcmV4aXN0cyhjb25zdCBzdHJ1Y3QgaW50ZXJmYWNlICppZnApCit7
CisJY29uc3Qgc3RydWN0IGRoY3Bfc3RhdGUgKnN0YXRlOworCisJc3RhdGUgPSBEX0NTVEFURShp
ZnApOworCXJldHVybiAoc3RhdGUgJiYgc3RhdGUtPmFkZHIuc19hZGRyICE9IElOQUREUl9BTlkp
OworfQorCitpbnQKIGlwdjRfYWRkcmV4aXN0cyhzdHJ1Y3QgZGhjcGNkX2N0eCAqY3R4LCBjb25z
dCBzdHJ1Y3QgaW5fYWRkciAqYWRkcikKIHsKIAlzdHJ1Y3QgaW50ZXJmYWNlICppZnA7CmRpZmYg
LS1naXQgYS9leHRlcm5hbC9ic2QvZGhjcGNkL2Rpc3QvaXB2NC5oIGIvZXh0ZXJuYWwvYnNkL2Ro
Y3BjZC9kaXN0L2lwdjQuaAppbmRleCAzMWMzYzhlLi5hMzQzYmE4IDEwMDY0NAotLS0gYS9leHRl
cm5hbC9ic2QvZGhjcGNkL2Rpc3QvaXB2NC5oCisrKyBiL2V4dGVybmFsL2JzZC9kaGNwY2QvZGlz
dC9pcHY0LmgKQEAgLTY3LDYgKzY3LDcgQEAgdm9pZCBpcHY0X3NvcnRpbnRlcmZhY2VzKHN0cnVj
dCBkaGNwY2RfY3R4ICopOwogdWludDhfdCBpbmV0X250b2NpZHIoc3RydWN0IGluX2FkZHIpOwog
aW50IGluZXRfY2lkcnRvYWRkcihpbnQsIHN0cnVjdCBpbl9hZGRyICopOwogdWludDMyX3QgaXB2
NF9nZXRuZXRtYXNrKHVpbnQzMl90KTsKK2ludCBpcHY0X2lmYWRkcmV4aXN0cyhjb25zdCBzdHJ1
Y3QgaW50ZXJmYWNlICopOwogaW50IGlwdjRfYWRkcmV4aXN0cyhzdHJ1Y3QgZGhjcGNkX2N0eCAq
LCBjb25zdCBzdHJ1Y3QgaW5fYWRkciAqKTsKIAogI2RlZmluZSBTVEFURV9BRERFRAkJMHgwMQpA
QCAtOTQsNyArOTUsNyBAQCB2b2lkIGlwdjRfY3R4ZnJlZShzdHJ1Y3QgZGhjcGNkX2N0eCAqKTsK
ICNkZWZpbmUgaXB2NF9mcmVlcm91dGVzKGEpIHt9CiAjZGVmaW5lIGlwdjRfZnJlZShhKSB7fQog
I2RlZmluZSBpcHY0X2N0eGZyZWUoYSkge30KLSNkZWZpbmUgaXB2NF9hZGRyZXhpc3RzKGEsIGIp
ICgwKQorI2RlZmluZSBpcHY0X2lmYWRkcmV4aXN0cyhhKSAoMCkKICNlbmRpZgogCiAjZW5kaWYK
--94eb2c09538e8d35ca0541293d61--