IFF_RUNNING and hostapd

[David Sommerseth]

On 25/10/10 21:07, Dave Taht wrote:
> On Mon, Oct 25, 2010 at 11:40 AM, David Sommerseth
>>> It seems like a good idea to leave it in the NO CARRIER state until
>>> the first client authenticates.
>>
>> I do disagree with this, because that will not make it possible to start
>> radvd before at least one client has connected and the state has
>> changed.  And what when the last client disconnects, should it go back
>> to NO-CARRIER (dormant state)?
> 
> I am under the impression that radvd will start when an interface is
> disabled if configured to do so. I do not know how or if it monitors
> changes in state in an interface.

I haven't studied all the details of radvd configuration possibilities,
so I might have overseen some details.  I am not completely sure how the
IgnoreIfMissing {on,off} configuration option will work in reality.  But
that will still not solve the case, even if radvd starts.  As it will
not broadcast stateless IPv6 configurations, due to it will lack the
permissions of doing so when the interface is not in a RUNNING state.

> The advantage to my thinking is that routes from elsewhere to the
> wireless lan would not be offered via radvd (or babeld) until after
> something is actually up, and that routes would be withdrawn soon
> after the last device disconnects. This would cut down unnecessary
> traffic to the wireless router in question.

That is true, but I'm not sure that is the core idea behind the
IFF_RUNNING state.

--linux-2.6.32.16/Documentation/networking/operstates.txt-------------

__LINK_STATE_DORMANT, maps to IFF_DORMANT:

Set by the driver to express that the device cannot yet be used
because some driver controlled protocol establishment has to
complete. Corresponding functions are netif_dormant_on() to set the
flag, netif_dormant_off() to clear it and netif_dormant() to query.

On device allocation, networking core sets the flags equivalent to
netif_carrier_ok() and !netif_dormant().
----------------------------------------------------------------------

For me, this translates into that the device should be enabled (doing an
netif_dormant_off() and netif_carrier_ok() calls somehow) when it is
ready to communicate.  When hostapd is running and done initialising, I
would expect that to be the "ready signal", thus moving the device over
to IFF_RUNNING (via netif_dormant_off() and netif_carrier_ok() user
space equivalents)

The kernel documentation here is not too clear about a wireless device
being an AP mode.  Being in traditional client mode the docs seems to
make a lot more sense.

--linux-2.6.32.16/Documentation/networking/operstates.txt-------------

So basically a 802.1X supplicant interacts with the kernel like this:

-subscribe to RTMGRP_LINK
-set IFLA_LINKMODE to 1 via RTM_SETLINK
-query RTM_GETLINK once to get initial state
-if initial flags are not (IFF_LOWER_UP && !IFF_DORMANT), wait until
 netlink multicast signals this state
-do 802.1X, eventually abort if flags go down again
-send RTM_SETLINK to set operstate to IF_OPER_UP if authentication
 succeeds, IF_OPER_DORMANT otherwise
-see how operstate and IFF_RUNNING is echoed via netlink multicast
-set interface back to IF_OPER_DORMANT if 802.1X reauthentication
 fails
-restart if kernel changes IFF_LOWER_UP or IFF_DORMANT flag

if supplicant goes down, bring back IFLA_LINKMODE to 0 and
IFLA_OPERSTATE to a sane value.

A routing daemon or dhcp client just needs to care for IFF_RUNNING or
waiting for operstate to go IF_OPER_UP/IF_OPER_UNKNOWN before
considering the interface / querying a DHCP address.
----------------------------------------------------------------------

Even though this might be interpreted to work like you indicated, which
makes sense according to the very last paragraph, there is still an
important piece missing.  The network device needs to be pulled out of a
dormant state and set to IFF_RUNNING state at some point before any
routing daemon will start to do its job properly.  This is not happening
now.

At least on this point the docs is clear, and this is basically what is
failing currently.  Which can explain why the radvd process is not
allowed to write messages to an interface when not being in IFF_RUNNING
mode.  The kernel obviously blocks such attempts.

If radvd (or babeld or other daemons) should support auto-enabling the
devices based the device state, still requires the state to be changed
somehow.  Whether it is correct to do so, based upon if clients are
connected or not is another discussion.  (And possible pure radvd and
babeld issues is not the topic for this mailing list either)


kind regards,

David Sommerseth