Skip site navigation (1)Skip section navigation (2)
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>