[Patch v3] supplicant: add dbus getter method for nl80211 iftype

[Avinash Patil]

Hi Jouni,

Connection manager in discussion is "Connman". Here is link:
https://01.org/connman.

Simultaneous AP/STA operations are expected using wpa_supplicant.
Since mlan0 is interface with smaller ifindex, connman tries to start AP
operation
on mlan0 interface and fails because it cannot change iftype.

So an approach is expected where current interface type(station/AP) for
particular ifindex can be known beforehand.
This information would be used by Connman to decide whether to start AP or
move to next interface.

Similar logic can be extended to other interfaces- e.g. start station
operations only when iftyt)pe is STATION; start
P2P client operations only when iftype P2P_CLIENT. This is reason why I
have used  (nl80211_iftype_str() output).
To ensure output string to dbus application is driver independent, I will
modify patch so as to send generic strings e.g.-
AP, STATION, P2P_CLIENT & P2P_GO. All other strings can be moved to
"UNKNOWN" iftype for now.

>That looks pretty complex. What is that needed for? I'd rather limit
>this type of change to as small number of locations as possible rather
>than expecting all places touching association, deauthentication,
>disassociation, etc. to be aware of this special notification event.

Notification handlers were suggested by Dan Williams so that connection
manager or other applications would come to know when iftype changes.
I have already ensured notification handlers are introduced at minimal
places- only for functions where mode change operation happens.
Please let me know if any of these look redundant to you and I would remove
them.

Thanks,
Avinash


On Sun, Dec 14, 2014 at 9:33 PM, Jouni Malinen <j at w1.fi> wrote:
>
> On Thu, Dec 04, 2014 at 11:41:45PM +0530, Avinash Patil wrote:
> > This patch adds dbus getter method for nl80211 iftype.
> > This is required by certain applications which intend to start
> > AP operations only if current interface type is AP.
> > Getter method for capabilities cannot be used for this purpose as
> > this enumarates all the supported interface types.
>
> This is exposing an internal nl80211 specific debug string
> (nl80211_iftype_str() output) through a D-Bus interface that is supposed
> to be independent of the used driver interface.
>
> I don't think I fully understand the use case where this would really be
> needed in this scope. The use case you described previously was to
> figure out whether an AP mode can be started and that determination is
> somehow made by "certain applications". This seems to imply that such
> applications would need to be aware of the constraint of AP being usable
> only if the current interface type is already AP.. That does not sound
> reasonable expectation to me.
>
> In other words, I cannot really understand how this is supposed to work
> cleanly. Either there are some other use cases that I have not yet
> understood or this is way too more complex design for something as
> simple as indicating whether an AP mode operation could be supported on
> an interface.
>
> Patch also adds notification handlers for interface type change
> > events.
>
> That looks pretty complex. What is that needed for? I'd rather limit
> this type of change to as small number of locations as possible rather
> than expecting all places touching association, deauthentication,
> disassociation, etc. to be aware of this special notification event.
>
> --
> Jouni Malinen                                            PGP id EFC895FA
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20141218/9fe4c8fb/attachment.htm>