After the introduction of SIOCSIFCREATE2 and respective changes to ifconfig(8), some valid ifconfig command lines started to fail. How-To-Repeat: Checked out ifconfig dated just before the change: 2006.07.09.00.00.00. Compiled it all right. Using it: dg# ./ifconfig vlan77 create vlan 77 vlandev xl0 up dg# ./ifconfig vlan77 vlan77: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:50:04:9d:be:f1 media: Ethernet autoselect (100baseTX <full-duplex>) status: active vlan: 77 parent interface: xl0 dg# ./ifconfig vlan77 destroy dg# ./ifconfig vlan77 create vlan 77 vlandev xl0 mtu 1006 up dg# ./ifconfig vlan77 vlan77: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1006 ether 00:50:04:9d:be:f1 media: Ethernet autoselect (100baseTX <full-duplex>) status: active vlan: 77 parent interface: xl0 dg# ./ifconfig vlan77 destroy All OK... Now using the stock ifconfig: dg# ifconfig vlan77 create vlan 77 vlandev xl0 up ifconfig: ioctl (SIOCGIFFLAGS): no such interface dg# ifconfig vlan77 create vlan 77 vlandev xl0 mtu 1006 up ifconfig: ioctl (set mtu): Device not configured ifconfig: ioctl (SIOCGIFFLAGS): no such interface dg# ifconfig vlan77 ifconfig: interface vlan77 does not exist Total failure, the interface wasn't created at all.
In addition, it can be proved that the bug is caused or triggered by the SIOCSIFCREATE2 change and not another change: cvs update of ifconfig to time right after the change results in the buggy behaviour described in this PR. -- Yar
Any progress on this change? P.S. For the GNATS record it is spelt SIOCIFCREATE2 BMS
It appears that this problem is not limited to vlan(4), any cloned interface can suffer from it. The cause of the problem hides in rev. 1.2 of sbin/ifconfig/ifclone.c. Due to that change, interface creation is handled now by a callback, which is invoked after all parameters were processed. E.g., if one writes "ifconfig lo5 create mtu 1500 up", ifconfig will try to set the mtu and flags from the main command loop and fail before the create callback has a chance to bring the interface into existence. A possible workaround for vlan(4) is to avoid such parameters as "mtu" or "up" in "ifconfig vlanX create ...". The "vlan" and "vlandev" parameters are processed from a callback, too, so they don't fail. I.e., the following command will work: ifconfig vlan55 create 10.55.55.1/24 vlan 55 vlandev em0 Note that you don't need an explicit "up" as long as an IP address is assigned to the interface -- the IP layer will bring it up anyway. -- Yar
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
This ancient PR seems to be fixed now: fernape@beastie:~/test$ sudo ifconfig vlan77 create vlan 77 vlandev re0 up Password: fernape@beastie:~/test$ ifconfig vlan77 vlan77: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=80001<RXCSUM,LINKSTATE> ether 00:1e:8c:b5:fc:3b inet6 fe80::21e:8cff:feb5:fc3b%vlan77 prefixlen 64 scopeid 0x5 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active vlan: 77 vlanpcp: 0 parent interface: re0 groups: vlan fernape@beastie:~/test$ uname -a FreeBSD beastie 11.1-RELEASE-p4 FreeBSD 11.1-RELEASE-p4 #0: Tue Nov 14 06:12:40 UTC 2017 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
Fixed long time ago.