Hi,
I'm a but confused about what fields in "struct
cfg80211_connect_params" (now abbreviated as sme->)
are relevant for me.
sme->private
------------
Right now, my lbs_cfg_connect() code just tests
sme->crypto.cipher_group. It doesn't check or use sme->privacy.
and sme-> crypto.wpa_versions like they are redundant. Is this
correct?
Empirical it migth be correct, because I can successfully connect
to APs, but if "privacy" is redundant, should I prepare a patch
to get rid of it?
What is this? And how should my driver react to it's settings?
sme->crypto.wpa_versions
------------------------
Again I seems to be ok to ignore this variable and just check
sme->crypto.cipher_group. In practice this seems to work, but is
it correct?
What is this, what is the intented use of it? May I prepare a
patch to get rid of it?
sme->crypto.n_ciphers_pairwise, sme->crypto.ciphers_pairwise
------------------------------------------------------------
The same for sme->crypto.n_ciphers_pairwise. It is always 0 zero
for the WEP case and always 1 for the WPA/WPA2 case, so isn't it
redundant either? lbs_cfg_connect() ignores this, maybe it's
not needed at .connect() time anyway?
But what is it really, what is the intended use?
sme->crypto.n_akm_suites, sme->crypto.akm_suites
------------------------------------------------
In cfg80211.h, the kdoc help text for sme->crypo.akm_suites is
just "AKM suites" or "number of AKM suites", which keeps me as
confused as before.
What is this? And how should my driver react to it's settings?
--
http://www.holgerschurig.de
On Mon, 2009-10-26 at 13:11 +0100, Holger Schurig wrote:
> inside .connect() if I check sme->crypto.cipher_suite for
>
> WLAN_CIPHER_SUITE_WEP40
> WLAN_CIPHER_SUITE_WEP104
> WLAN_CIPHER_SUITE_TKIP
> WLAN_CIPHER_SUITE_CCMP
> 0 (meaning no encryption/WEP obfuscation)
But why would you look at that? It sounds like you want sme->privacy to
know whether to select an AP that advertises privacy or not?
johannes
> > sme->crypto.wpa_versions
>
> > sme->crypto.n_ciphers_pairwise, sme->crypto.ciphers_pairwise
>
> > sme->crypto.n_akm_suites, sme->crypto.akm_suites
>
> All these pretty much exist for hw that doesn't want to use the
> IE(s) contained in the connect parameters. If you send an assoc
> request with those IEs, you can safely ignore the parameters
> here. It's just there so one doesn't have to parse the IEs.
Okay, then I conclude that it's save to ignore
sme->privacy
sme->crypto.wpa_versions
sme->crypto.n_ciphers_pairwise
sme->crypto.ciphers_pairwise
sme->crypto.n_akm_suites
sme->crypto.akm_suites
inside .connect() if I check sme->crypto.cipher_suite for
WLAN_CIPHER_SUITE_WEP40
WLAN_CIPHER_SUITE_WEP104
WLAN_CIPHER_SUITE_TKIP
WLAN_CIPHER_SUITE_CCMP
0 (meaning no encryption/WEP obfuscation)
lbs_cfg_connect() calls lbs_associate() which hands the complete
sme->ie to as a TLV to the firmware. However, I don't do any
parsing of sme->ie by myself.
--
http://www.holgerschurig.de
On Mon, 2009-10-26 at 13:59 +0100, Holger Schurig wrote:
> lbs_cfg_connect:
> if (sme->bssid set) {
> # I need a full cfg80211_bss entry, because I can only
> # associate to a specific bss via CMD_802_11_ASSOCIATE
> # and I need
> # bss->capability
> # bss->bssid
> # bss->get_ie(WLAN_EID_SSID)
> # bss->channel
> # bss->rates
> bss = cfg80211_get_bss()
You need sme->privacy here.
> However, this current setup makes "iw abc connect SSID"
> non-working with libertas. It would work with libertas if I
> would use the .auth/.assoc API, because then net/wireless/sme.c
> would scan for me. But in the .connect API case, it doesn't do
> this.
>
> But information I get in the .connect() call aren't sufficuent
> for the Libertas firmware interface, I need more data, which I
> can get from a cfg80211_bss entry.
>
> One possiblity is that net/wireless/sme.c get's more general and
> does scan in the .connect() case, too.
>
> Or I could substitute the "error_out" with a local scan, and then
> select the "best" AP from the bss list. I fear however that such
> a selection function might already be somewhere inside
> net/wireless/*.c, I'll need to search for that.
There isn't really. It _might_ be possible to further abstract this out,
but that means we need to _first_ be able to advertise device roaming
capabilities so that we _don't_ select a specific BSS for devices that
want to handle roaming like iwm.
johannes
On Mon, 2009-10-26 at 09:47 +0100, Holger Schurig wrote:
> I'm a but confused about what fields in "struct
> cfg80211_connect_params" (now abbreviated as sme->)
> are relevant for me.
>
>
> sme->private
> ------------
I think you mean "privacy". I'm not sure about it right now, would have
to dig, but maybe the answer to the others helps you?
> sme->crypto.wpa_versions
> sme->crypto.n_ciphers_pairwise, sme->crypto.ciphers_pairwise
> sme->crypto.n_akm_suites, sme->crypto.akm_suites
All these pretty much exist for hw that doesn't want to use the IE(s)
contained in the connect parameters. If you send an assoc request with
those IEs, you can safely ignore the parameters here. It's just there so
one doesn't have to parse the IEs.
johannes
> > inside .connect() if I check sme->crypto.cipher_suite for
> >
> > WLAN_CIPHER_SUITE_WEP40
> > WLAN_CIPHER_SUITE_WEP104
> > WLAN_CIPHER_SUITE_TKIP
> > WLAN_CIPHER_SUITE_CCMP
> > 0 (meaning no encryption/WEP obfuscation)
>
> But why would you look at that? It sounds like you want
sme->privacy to
> know whether to select an AP that advertises privacy or not?
Libertas' firmware doesn't have a capability of to "select an AP
that advertises privacy". So in practice it's wpa_supplicant that
selects this, because pure iw/cfg80211 can't select an AP for
me.
My connect method does this:
lbs_cfg_connect:
if (sme->bssid set) {
# I need a full cfg80211_bss entry, because I can only
# associate to a specific bss via CMD_802_11_ASSOCIATE
# and I need
# bss->capability
# bss->bssid
# bss->get_ie(WLAN_EID_SSID)
# bss->channel
# bss->rates
bss = cfg80211_get_bss()
} else {
error_out
}
clear_local_wep_key_copy
switch (sme->cryto.cipher_group) {
case WEP40, WEP104:
store_key_keyidx_locally
set_wep_keys
enable_wep_in_lbs_mac
disable_rsn
break;
case no_encryption:
case WPA, WPA2:
remove_wep_keys
disable_wep_in_lbs_mac
clear_wpa_wpa2_unicast_multicast_key
unless no_encryption:
enable_rsn
}
build_and_submit_set_authtype_command_for_the_firmware
build_and_submit_associate_command_for_the_firmware
You see, nowhere do I actually need sme->privacy, all info is in
sme->crypto.cipher_group.
However, this current setup makes "iw abc connect SSID"
non-working with libertas. It would work with libertas if I
would use the .auth/.assoc API, because then net/wireless/sme.c
would scan for me. But in the .connect API case, it doesn't do
this.
But information I get in the .connect() call aren't sufficuent
for the Libertas firmware interface, I need more data, which I
can get from a cfg80211_bss entry.
One possiblity is that net/wireless/sme.c get's more general and
does scan in the .connect() case, too.
Or I could substitute the "error_out" with a local scan, and then
select the "best" AP from the bss list. I fear however that such
a selection function might already be somewhere inside
net/wireless/*.c, I'll need to search for that.
--
http://www.holgerschurig.de
On Mon, 2009-10-26 at 09:47 +0100, Holger Schurig wrote:
> Hi,
>
> I'm a but confused about what fields in "struct
> cfg80211_connect_params" (now abbreviated as sme->)
> are relevant for me.
>
>
> sme->private
> ------------
> Right now, my lbs_cfg_connect() code just tests
> sme->crypto.cipher_group. It doesn't check or use sme->privacy.
>
> and sme-> crypto.wpa_versions like they are redundant. Is this
> correct?
>
> Empirical it migth be correct, because I can successfully connect
> to APs, but if "privacy" is redundant, should I prepare a patch
> to get rid of it?
>
> What is this? And how should my driver react to it's settings?
>
>
>
> sme->crypto.wpa_versions
> ------------------------
> Again I seems to be ok to ignore this variable and just check
> sme->crypto.cipher_group. In practice this seems to work, but is
> it correct?
>
> What is this, what is the intented use of it? May I prepare a
> patch to get rid of it?
Wouldn't this be used to force WPA2/RSN? THere are APs out there where
you can select WPA+CCMP and WPA2+TKIP, which wouldn't be apparent from
just cipher_group, right? If userspace really does want you to only
connect to a WPA2-capable AP and ignore WPA1+TKIP and WPA1+CCMP, then
this field is the only way to indicate that.
In libertas, this would all happen during the scan-before-connect when
we try to find the BSSID of the AP we want to associate with. The WEXT
stuff had a bunch of ugly checks to match up an AP in the scan list with
the parameters of the connect request, and that's where I'd expect this
to be used?
Dan
>
>
> sme->crypto.n_ciphers_pairwise, sme->crypto.ciphers_pairwise
> ------------------------------------------------------------
> The same for sme->crypto.n_ciphers_pairwise. It is always 0 zero
> for the WEP case and always 1 for the WPA/WPA2 case, so isn't it
> redundant either? lbs_cfg_connect() ignores this, maybe it's
> not needed at .connect() time anyway?
>
> But what is it really, what is the intended use?
>
>
>
> sme->crypto.n_akm_suites, sme->crypto.akm_suites
> ------------------------------------------------
> In cfg80211.h, the kdoc help text for sme->crypo.akm_suites is
> just "AKM suites" or "number of AKM suites", which keeps me as
> confused as before.
>
> What is this? And how should my driver react to it's settings?
>
>