ifconfig(8) utility has an ability to automatically load necessary kernel module when creating first instance of a new (say, dynamic) interface. Sometimes it works (e.g. ifconfig crate tap0) and sometimes doesn't (ifconfig create vmnet0). Fix: This problem is most probably caused by the ifmaybeload() function. It implicitly derives kernel module name from the interface name by removing numerical suffix and prepending "if_" prefix. Whereas both tap and vmnet interfaces share the same if_tap.ko kernel module, and there is no separate if_vmnet.ko one. Possible workaround (successfully tested): during installkernel make a copy (or hardlink) of if_tap.ko under the name if_vmnet.ko, that works fine. By the way, it makes sense to hardlink tap(4) and vmnet(4) manual pages too. Comment: I woudn't dare recommend suggested workaround as an ultimate solution because of possible unforeseen pitfalls (such as filesystems incapable of hardlinks etc.). How-To-Repeat: Boot with a clean GENERIC kernel. Become root. Say "ifconfig vmnet0 create". You should get "ifconfig: SIOCIFCREATE2: Invalid argument" diagnostics. At the same time "ifconfig tap0 create" works as expected (as well as "ifconfig vmnetN create" afterwards, when if_tap.ko is already loaded).
Responsible Changed From-To: freebsd-bugs->freebsd-net this is kind of a generic problem with interface naming.
Creating hardlinks for the device drivers is simple and fixing the driver names in head to be consistent across the board (no hardlinks) seems like a relatively straightforward task. Take.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.