drv->has_capability and GET_CAPABILITY

[Dan Williams]

On Mon, 2006-08-21 at 09:21 -0700, Jouni Malinen wrote:
> On Mon, Aug 21, 2006 at 06:33:13AM -0400, Dan Williams wrote:
> 
> > wpa_supplicant_ctrl_iface_get_capability() seems to assume that an
> > interface that fails the capability check has _all_ capabilities.  If
> > the return value from wpa_drv_get_capa() is -1, then for a request for
> > 'pairwise' the control interface will return "CCMP TKIP NONE".
> 
> Yes, that is the generic assumption in wpa_supplicant. If the driver
> does not support capability query, it is assumed to support everything
> in order to avoid reducing functionality.
> 
> > If drv->has_capability is 0, that usually means that wpa_supplicant
> > couldn't determine what the capabilities of the interface are, or the
> > driver is old.  The wext driver only sets has_capability if the driver
> > is WE-18 or later.  If my reading is right, any driver compiled for WE <
> > 18 will report through the control interface that it supports WPA.  Is
> > that correct?
> 
> Yes, that's correct.
> 
> > It seems that if wpa_supplicant cannot determine what capabilities the
> > interface supports, it reports support for all capabilities.  That seems
> > broken to me, but probably was added as a kludge to allow older,
> > non-standard drivers to use WPA even though they did not report
> > capabilities correctly, or for pre-WE WPA support.  The problem I have
> > is that I cannot rely on wpa_supplicant to reliably report what the
> > capabilities for an interface are then.
> 
> That is be design. If all your drivers support capability query, the
> result should be reliable.
> 
> > What I'd like to do in the dbus control interface is diverge from the
> > socket/UDP control interface and be more conservative in reporting
> > capabilities.  But then the interfaces differ.  Does that sound fine?
> 
> I would recommend not to do this and rather concentrate on adding
> support for drivers to report their capabilities. I would like to see
> all control interfaces showing the same results. However, if you think
> that there is need for reporting only the capabilities that the driver
> explicitly advertised, I would be willing to live with an extra argument
> to GET_CAPABILITY (on all ctrl_ifaces) for not defaulting to all
> enabled. In other words, there could be "GET_CAPABILITY pairwise" with
> current behavior and "GET_CAPABILITY pairwise strict" for requesting the
> list in the way you would like to see it here.

Ok, that seems reasonable.

I guess I take the line with NM that until your driver is actually
proven to work correctly, you don't get that functionality exposed in
the UI.  But it's reasonable to have wpa_supplicant do this, I guess.

I'll see if I can whip ip a quick 'strict' patch then.  Another large
dbus update coming down the pipe soon too.

Dan