<div dir="ltr">Hi Jouni,<div><br></div><div>Connection manager in discussion is "Connman". Here is link:</div><div><a href="https://01.org/connman">https://01.org/connman</a>.</div><div><br></div><div>Simultaneous AP/STA operations are expected using wpa_supplicant.</div><div>Since mlan0 is interface with smaller ifindex, connman tries to start AP operation</div><div>on mlan0 interface and fails because it cannot change iftype.</div><div><br></div><div>So an approach is expected where current interface type(station/AP) for particular ifindex can be known beforehand.</div><div>This information would be used by Connman to decide whether to start AP or move to next interface.</div><div><br></div><div>Similar logic can be extended to other interfaces- e.g. start station operations only when iftyt)pe is STATION; start</div><div>P2P client operations only when iftype P2P_CLIENT. This is reason why I have used (nl80211_iftype_str() output).</div><div>To ensure output string to dbus application is driver independent, I will modify patch so as to send generic strings e.g.-</div><div>AP, STATION, P2P_CLIENT & P2P_GO. All other strings can be moved to "UNKNOWN" iftype for now.</div><div> </div><div>>That looks pretty complex. What is that needed for? I'd rather limit</div>>this type of change to as small number of locations as possible rather<br>>than expecting all places touching association, deauthentication,<br>>disassociation, etc. to be aware of this special notification event.<div><br></div><div>Notification handlers were suggested by Dan Williams so that connection manager or other applications would come to know when iftype changes.</div><div>I have already ensured notification handlers are introduced at minimal places- only for functions where mode change operation happens.</div><div>Please let me know if any of these look redundant to you and I would remove them.</div><div><br></div><div>Thanks,</div><div>Avinash <br><div></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 14, 2014 at 9:33 PM, Jouni Malinen <span dir="ltr"><<a href="mailto:j@w1.fi" target="_blank">j@w1.fi</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On Thu, Dec 04, 2014 at 11:41:45PM +0530, Avinash Patil wrote:<br>
> This patch adds dbus getter method for nl80211 iftype.<br>
> This is required by certain applications which intend to start<br>
> AP operations only if current interface type is AP.<br>
> Getter method for capabilities cannot be used for this purpose as<br>
> this enumarates all the supported interface types.<br>
<br>
</span>This is exposing an internal nl80211 specific debug string<br>
(nl80211_iftype_str() output) through a D-Bus interface that is supposed<br>
to be independent of the used driver interface.<br>
<br>
I don't think I fully understand the use case where this would really be<br>
needed in this scope. The use case you described previously was to<br>
figure out whether an AP mode can be started and that determination is<br>
somehow made by "certain applications". This seems to imply that such<br>
applications would need to be aware of the constraint of AP being usable<br>
only if the current interface type is already AP.. That does not sound<br>
reasonable expectation to me.<br>
<br>
In other words, I cannot really understand how this is supposed to work<br>
cleanly. Either there are some other use cases that I have not yet<br>
understood or this is way too more complex design for something as<br>
simple as indicating whether an AP mode operation could be supported on<br>
an interface. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
> Patch also adds notification handlers for interface type change<br>
> events.<br>
<br>
</span>That looks pretty complex. What is that needed for? I'd rather limit<br>
this type of change to as small number of locations as possible rather<br>
than expecting all places touching association, deauthentication,<br>
disassociation, etc. to be aware of this special notification event.<br>
<div><div><br>
--<br>
Jouni Malinen PGP id EFC895FA<br>
</div></div></blockquote></div></div></div></div></div>