IFF_RUNNING and hostapd

[Dave Taht]

On Mon, Oct 25, 2010 at 4:11 PM, David Sommerseth
<hostapd.list at topphemmelig.net> wrote:
> On 25/10/10 21:07, Dave Taht wrote:
>> On Mon, Oct 25, 2010 at 11:40 AM, David Sommerseth wrote

[snip]

> 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)

1) From what you've described it sounds like the problem can be solved
within hostap? Merely by modifying (at least in my case) the
linux_set_iface_flags function in src/drivers/linux_ioctl.c to treat
the "UP" state as UP | IFF_RUNNING?

(I'm away from my cross compiler otherwise I'd have tried this already
today) Or does it require a kernel change to reflect this issue within
bridged/non-bridged modes?

Merely setting IFF_RUNNING on non-bridged interfaces would take us
from IPv6 not-working-at-all in non-bridged AP mode to working, which
would be rather good. At the moment, I'd settle for that. :)

2) Adding a configuration variable and logic  to hostap to control
IFF_RUNNING in either of the modes described, with the default as you
describe, might be better. I don't think radvd or babeld need to
twiddle with the state of the interface itself, they have enough to
do. (it would be good if they were more responsive to changes)

The big flaw in my thinking, as I think about it, is that routing
protocols tend to take a while to propagate, and IPv6 autoconfig
should "just work", so changing the interface state on the fly on the
first client connect would introduce more instability to the network
than not.

The traffic control problem (while real) is separate from having
traffic work at all...

so what's fast and reliable and works - works for me. I'll patch the
aformentioned file and hope it works later this evening. If it's
deeper in the stack than that, (which I suspect), I'll fall over the
edge again....


>
>
> kind regards,
>
> David Sommerseth
>



-- 
Dave T?ht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com