When the autoconf flag flaps around we might end up with multiple bpf
FDs in flight. Things then get confusing. The kernel tells us we can
read from the bpf FD but the data is actually "on the other FD", so
read(2) returns 0.
Found the hard way by, and patiently debugged with weerd@
One way to trigger this is booting a vmm VM where dhcpleased(8)'s
init_ifaces() loses a race against netstart(8). init_ifaces() would
already see the autoconf flag and request a bpf FD.
But then it would receive a RTM_IFINFO message without the autoconf flag
set from when the interface came up. Then it will see another RTM_IFINFO
message with the autoconf flag set and request yet another bpf FD. If
the first bpf FD had not arrived yet we ended up with two in the frontend
process.
While here make sure a bpf FD has been received for an iface before
trying to close(2) it.
tweak & OK dv