When i will set a name of the interface with same name of group the system will crash immmediatetly. Example: ifconfig tap0 create ifconfig tap0 name test group test 11-STABLE but, also tested on 11-RELEASE-p9
I can't reproduce this on current. Do you happen to have pf loaded? I'm aware that pf doesn't handle this. The basic problem is that pf assumes that interfaces and groups live in the same namespace. That's not the case, and this mistaken assumption causes pf to panic the system. It's a nontrivial fix, because the best way (in my view at least) to fix this is to actually make groups and interfaces share a namespace. It's downright silly to have a group foo and an interface foo at the same time, especially because there's no obligation for interface foo to be a member of group foo. I suspect this became a problem when the ability to change interface names was introduced. It used to be the case that interfaces were always foo0 or bar1. In fact, groups still refuse to be named baz3 ("ifconfig: setifgroup: group names may not end in a digit").
Yes, with pf loaded: root@fbsd:~ # uname -a FreeBSD fbsd.lab.local 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 #0: Tue Apr 11 08:48:40 UTC 2017 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 root@fbsd:~ # kldload pf root@fbsd:~ # ifconfig lagg0 create root@fbsd:~ # ifconfig lagg0 name test group test <6>lagg0: changing name to 'test' Fatal double fault rip = 0xffffffff80ad4d34 rsp = 0xfffffe0000218fe0 rbp = 0xfffffe0000219070 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff80b24477 at kdb_backtrace+0x67 Uptime: 3m23s Dumping 103 out of 991 MB: without pf, everything works normally
*** Bug 221492 has been marked as a duplicate of this bug. ***
*** Bug 154214 has been marked as a duplicate of this bug. ***
*** Bug 256815 has been marked as a duplicate of this bug. ***
Note that this no longer causes pf to panic. See b2e0b24f76066fc52abe4330772c41996eca8bf8 (from Sat Dec 1 09:58:21 2018). The underlying problem is still there, and if you do this you're going to have some very unexpected and difficult to understand behaviour in pf, but at least it doesn't panic any more. I've looked at fixing this, but there's no error handling in many of the group/interface name assignment paths and the locking .. well, either I completely fail to understand it, or it's mostly wrong.