beacons and ibss + rsn
greearb at candelatech.com
Tue Apr 14 15:44:53 EDT 2015
On 04/14/2015 12:39 PM, Jouni Malinen wrote:
> 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
I can probably find it soon enough, but if you have a pointer to
code that would be setting up beacons with block-ack flagged as supported
or not, that might help me find it quicker...
I think I am also missing some RFC patches that enable VHT80..maybe
some of that will point me in the right direction as well.
>> 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\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.
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the HostAP