Created attachment 219229 [details]
On some virtual machines (e.g. on VirtualBox, on the cloud platform Vultr, etc.), restarting a vtnet interface configured with DHCP fails to restart dhclient.
Because the driver 'if_vtnet' follows the driver requirements of the VIRTIO specification , LINK_UP is notified at most once (most probably during the boot process) when VIRTIO_NET_F_STATUS is not negotiated. As a result, dhclient can not be restarted via devd.
For a similar reason, it might be possible that LINK_UP is not emitted at the interface restart even in a variant scenario where VIRTIO_NET_F_STATUS is negotiated (I do not have access to a bhyve-capable computer right now so I am unable to test).
If SYNCDHCP is used to configure the interface, dhclient is restarted via netif/network.subr.
The attached patch makes dhclient start from two different ways (devd and netif/network.subr) when the interface is configured with DHCP. In that regard, DHCP would behave exactly like SYNCDHCP and inherit the same race that currently happens with SYNCDHCP when an interface is restarted .
• Mitigate the absence of LINK_UP notification to restart dhclient, at least when VIRTIO_NET_F_STATUS is not negotiated
• Remove a comment note (success of wpaif does imply interface configuration and wpa_supplicant does bring up the interface)
• Remove a trailing whitespace
 https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html (18.104.22.168 Driver Requirements, second paragraph)
 This race does not happen during the boot process because devd has not yet been started when netif runs). It is reproductible on a computer by configuring an interface with SYNCDHCP and executing, e.g., 'service netif restart wlan0' a dozen of times, or even more easily with a lagg interface by executing, e.g., 'service netif restart wlan0 lagg0'. It has no functional impact, but it makes one seriously wonder why 'dhclient is already running' whereas one just restarted one's interface...