Created attachment 219229 [details] Patch file Hi, 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 [1], 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 [2]. • 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 [1] https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html (5.1.4.2 Driver Requirements, second paragraph) [2] 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...
Your patch effectively makes DHCP and SYNCDHCP behave identical (except for the 'quiet' behaviour), so you could as well just use SYNCDHCP with the VLAN interfaces. Thus I don't think there is any necessity to modify network.subr.
I think I might have the same issue with vlan interfaces on vtnet interface (proxmox host with virtio interface), dhclient never starts at boot or later. Relevant rc.conf: vlans_vtnet0="vlan2 vlan10 vlan11 vlan12 vlan13 vlan14 vlan15 vlan16 vlan17 vlan18 vlan19 vlan40" ifconfig_vtnet0="inet ......" create_args_vlan12="vlan 12" ifconfig_vlan12="up DHCP" vlan12 is brought UP but dhclient is never launched at boot (or when trying restarting netif). Manually creating the device with "ifconfig vlan12 create vlan 12 vlandev vtnet0" gives the following event in devd: Pushing table setting *=!system=ETHERNET subsystem=vlan12 type=IFATTACH setting _=system=ETHERNET subsystem=vlan12 type=IFATTACH setting timestamp=1695243315.525712 setting system=ETHERNET setting subsystem=vlan12 setting type=IFATTACH Processing notify event The devd.conf has rule: # notify 0 { match "system" "IFNET"; match "type" "LINK_UP"; media-type "ethernet"; action "service dhclient quietstart $subsystem"; }; So, I added /etc/devd/vtnet-dhcp.conf: notify 20 { match "system" "ETHERNET"; match "type" "IFATTACH"; match "subsystem" "vlan.*"; media-type "ethernet"; action "service dhclient quietstart $subsystem"; }; With this added, vtnet-based vlan with DHCP works as expected (on boot, on netif restart)
I suspect this behaviour is visible in other drivers as well: I am seeing the same behaviour on a bge interface with several subinterfaces configured for "DHCP", but only the first one triggers devd to call "service dhclient ...". There are no subsequent LINK_UP events for other subinterfaces. The fix is to use "SYNCDHCP" instead which uses /etc/rc.d/netif to bring up the dhclients.