INTERFACE_DISABLED state handling
Thu Feb 16 09:02:48 PST 2012
I was studying through hostap/supplicant version 1.0. I see that WPA_INTERFACE_DISABLED, is one of the newer states added for handling the rfkill operations on the drivers/devices.
When, supplicant moves to WPA_INTERFACE_DISABLED, operations or events - SCAN, RECONNECT and REASSOCIATE are not handled and replied with error status. This is is understandable when rfkill indeed happens and the RF and thus the IP interface gets disabled.
However, there can be scenarios where rfkill is not forced and still a simple ip or net down is called on the interface (for example having been disassociated and hence there is not possible data link etc applications can call a ip or net down). This sends a link change notification to the supplicant which (in rtm_newlink handling) moves the state to WPA_INTERFACE_DISABLED as per the new state changes.
Now, if the application wanted to send a scan command to supplicant, then it would not be possible because the supplicant would reject it.
If the supplicant expects that the state should always be moved to WPA_INTERFACE_ENABLED before SCAN, RECONNECT, REASSOSCIATE? Wouldn't that mean, the ip or net up needs to be done even if the net traffic cannot be started? Would not this mean providing a wrong status to the application?
I am a little confused. I hope some one can throw some light.
Thanks in advance.
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Hostap