Re: Static vxlan configuration fails - probably because of wrong order in rc
Date: Tue, 26 Aug 2025 18:02:05 UTC
On 8/22/25 17:30, Patrick M. Hausen wrote: > Hi, > >> Am 22.08.2025 um 21:02 schrieb John Baldwin <jhb@FreeBSD.org>: >> >> A verbose dmesg of the two cases would probably be helpful. > > I set verbose_loading="YES", then booted two times, once without, once > with if_smsc_load="YES". > > -------- > $ diff dmesg-not-loaded.txt dmesg-loaded.txt > 10a11 >> module smsc already present! > 12c13 > < avail memory = 945016832 (901 MB) > --- >> avail memory = 944844800 (901 MB) > 178a180 >> vxlan0: Ethernet address: 58:9c:fc:00:82:82 > 182d183 > < vxlan0: Ethernet address: 58:9c:fc:00:82:82 > -------- That's not the full dmesg, just a diff. That said, USB devices are probed asynchronously in parallel with the early userland startup. If the USB ethernet device isn't attached by the time /etc/rc.d/netif runs, the the vxlan device is probably just not configured. (You haven't included `ifconfig` output in any of your e-mails, so I have to guess at what the status of vlxan0 might be in the non-working case.) The way wlanX and vlan devices are handled is that they are not "regular" clone devices, but instead are tied to a parent interface (e.g. wlans_foo0="wlanX" or vlans_foo0="foo0.123"). This means that `/etc/rc.d/netif/start foo0` (invoked by devd when a hot plug NIC such as USB is attached) is able to create those pseudo interfaces anytime a foo0 device arrives. This is what the last comment in your bug is referring to (in essence). You could create a custom config file for devd that brings the vlxan interface up when ue0 arrives as a local fix. A more general fix would be to add support for a 'vxlans_<IF>' variable similar to `vlans_<IF>' which would be a list of child vxlan interfaces. You would then just need `vxlans_ue0="vxlan0"` instead of cloned_interfaces="vxlan0" in rc.conf. -- John Baldwin