Network interface RUNNING and UP flags

Yar Tikhiy yar at comp.chem.msu.su
Sat Aug 7 02:58:06 PDT 2004


On Fri, Aug 06, 2004 at 05:50:04PM -0400, Coleman Kane wrote:
> Hi, I have been having some trouble working with getting tapN network
> interfaces into the 'RUNNING' state. I have been trying to figure out
> how to set the RUNNING flag on an interface, which is needed before
> the kernel will actually begin sending packets from said network
> interface. So far, the only way I have been able to figure out how to
> do this is to assign an IPv4 address to the interface, I am guessing
> that an un-addressed network interface is supposed to remain not
> RUNNING even if it is UP by design. The problem is that only an IPv4
> address assignment will bring it up and running. If I attempt to
> assign an IPv6 address to the interface, it will go UP, but not
> RUNNING. I have determined that I can assign an IPv4 address (such as
> 10.0.0.1) to it, and then subsequently remove it (via -alias) and this
> will leave the interface in the running state.
> 
> My questions are:
> 
> 1) Why doesn't assigning an IPv6 address produce the same side effects
> and
> 2) Is there a way to set this interface flag without assigning an IPv4
> address (or any address for that matter) first?
> 
> Mainly for number two, I would like to be able to run interfaces
> bridged together without having to also give all of them addresses.

As a matter of fact, the IFF_RUNNING flag, visible as ``RUNNING'' in
the output from ifconfig(8), is intended for interface's internal use
and should not influence the interaction of the interface with other
modules, except for affecting careful user's experience :-)

On the contrary, IFF_UP, a.k.a. ``UP'', is an administrative flag
to be toggled from outside an interface driver.  A user can flip
it to shutdown the interface, or a network stack module may touch
it if it needs to (e.g., IP will bring an interface up to send a
gratuitous ARP upon configuring an IP address on it.)

-- 
Yar


More information about the freebsd-hackers mailing list