beacons and ibss + rsn

Jouni Malinen j at w1.fi
Tue Apr 14 15:39:46 EDT 2015


On Tue, Apr 14, 2015 at 12:09:19PM -0700, Ben Greear wrote:
> I am trying to figure out why neither ath9k nor ath10k IBSS RSN
> interfaces are advertising block-ack features in their beacons
> (or probe responses).
> 
> I found this rather questionable piece of code while grepping
> around....maybe supplicant just doesn't support this sort
>o of thing properly at present?

I don't see how HT configuration and RSN IE within wpa_supplicant itself
would be related, but anyway, on this question regarding
supp_get_beacon_ie():

> static int supp_get_beacon_ie(void *ctx)
> {
>         struct ibss_rsn_peer *peer = ctx;
> 
>         wpa_printf(MSG_DEBUG, "SUPP: %s", __func__);
>         /* TODO: get correct RSN IE */
>         return wpa_sm_set_ap_rsn_ie(peer->supp,
>                                     (u8 *) "\x30\x14\x01\x00"
>                                     "\x00\x0f\xac\x04"
>                                     "\x01\x00\x00\x0f\xac\x04"
>                                     "\x01\x00\x00\x0f\xac\x02"
>                                     "\x00\x00", 22);
> }

This is for setting RSN element for the RSN supplicant component. This
is currently hardcoded to require use of PSK and CCMP for RSN IBSS case.
While in theory this could be made more accurately match what is
advertised in the IBSS, I'm not sure this can really be done very
robustly, i.e., each peer in the IBSS could end up having some
differences in the RSN element (e.g., which of the optional fields are
included) and more flexible per-peer selection based on advertised data
could be used. If someone really cares about IBSS, I'm sure there are
number of areas like this that could be improved.

-- 
Jouni Malinen                                            PGP id EFC895FA


More information about the HostAP mailing list