Date: Fri, 17 Apr 2015 01:15:42 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199136] [if_tap] Added down_on_close sysctl variable to tap(4) Message-ID: <bug-199136-2472-9hbR7eQxFy@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-199136-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-199136-2472@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199136 --- Comment #9 from yuri@rawbw.com --- > I'm strongly against the sysctl, and reasons are same as before. Sysctl knob is global. You can make it per-vnet, but your patch lacks that. You could even make it per-interface, but that would require quite a lot of extra code. Gleb, Default in this case is unreasonable. Consider this situation: admin makes tapN interface to initialize tap0 in /etc/rc.conf: cloned_interfaces="tap0; ifconfig_tap0="inet 192.168.2.1 up" tap0 is in "up" and initialized state from the system start. Now imagine virtual machine (say VirtualBox) is using tap0. This VM goes up, works, then shuts down. Now tap0 interface is "down", and has lost its IP address. The second and all subsequent run-cycles of VM will not be able to connect to the same network again, unless admin does 'ifconfig tap0 up; ifconfig tap0 inet ...' every time. This behavior is unreasonable in general, because *tapN driver has overridden the default tap0 state set by admin*, and decided that this interface should now be "down". VM run alters the system state in unintended fashion. > The IFF_LINK flag is a lesser patch, and immediately gives you a per-interface configuration granularity, which of course implies per-vnet. Setting flag in rc.conf requires same efforts as putting a line in sysctl.conf. Besides that IFF_LINK flags are generally cryptic in their nature, there is really no need to be able to fine-tune this on per-net or per-interface basis. > Changing the default is different question, and should be discussed separately. Yes, changing the default is what seems to be the most reasonable solution here. Please note that all users of tapN are more or less the same: they are the processes that need to connect to the network from the process side through the device /dev/tapN. They aren't aware of the network side of it, tapN interfaces. This side should behave reasonably as a system default behavior. My patch (the proposed new default) essentially *prevents any temporary tapN user from altering the system state defined by admin*. And with this new default tapN driver would bring the state back to what it was before tapN device was opened. I believe people who introduced vmnetN interfaces were solving the same exact problem. But vmnetN solution (morphing of tapN) seems to be an overkill. Because all users of tapN expect the same behavior. If you still disagree with the suggested new default, please describe the situation when tap0 is initialized before the use, and has to be reasonably expected to be "down" and lose its IP address after it is closed by the user. I propose to keep the old behavior net.link.tap.down_on_close=1 just in case for the off-chance that somebody actually depends on this behavior. But I don't think anybody should. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-199136-2472-9hbR7eQxFy>