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

[Avinash Patil]

--Resending from registered email ID as email bounced from hostap mailing
list---

Hi Jouni/Johannes,

Implementations may vary from vendor to vendor. One vendor implements it
this way does not mean all should follow the same, isnt it?
Interface capabilities/combination advertised by wiphy are per hardware
device and there is no restriction on how these this combination can be
supported. Single hardware device can be emulated to support multiple
virtual interfaces with different capabilities and that's what we intend to
do.

So when wiphy capabilities indicate support for AP interface, it does not
mean we should expect very first interface to be of AP type.
Driver can have multiple virtual interfaces and one of them would support
AP operation. So having right to know interface type is something that is
not expected??

Our current implementation cannot modify interface type(AP<=>STA) but still
we are able to support simultaneous AP/STA operations using
hostapd/wpa_supplicant.
Connman expects to control both using wpa_supplicant and this is where we
need to have support from supplicant to know interface type.

Also about notification handlers, if you are not OK with it, I would
completely remove notification handler related code.

Thanks,
Avinash

On Mon, Dec 22, 2014 at 2:45 PM, Jouni Malinen <j at w1.fi> wrote:

> On Thu, Dec 18, 2014 at 01:59:18PM +0530, Avinash Patil wrote:
> > 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.
>
> I don't understand this logic at all. Shouldn't the known capabilities,
> not the current interface type, be used to select which interface is
> used? wpas_dbus_getter_capabilities() is already exposing whether an
> interface can support AP mode.
>
> > 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.
>
> I don't really see any point in exposing the current interface type. I
> would not have any issues with exposing supported interface type(s).
>
> > 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.
>
> What would these be used for? I simply don't see the benefit or use case
> for exposing this. Your use case of being able to know whether AP mode
> operation can be used has nothing to do with what the current mode at
> any point in time happens to be. It has everything to do what the
> interface is capable of.. The current mode of an unused interface is
> pretty pointless information and if the interface is in use, you can
> already determine what its type is based on what kind of connection it
> is used for.
>
> --
> Jouni Malinen                                            PGP id EFC895FA
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20141222/d8bab102/attachment-0001.htm>