On Tue, May 31, 2011 at 11:10 AM, Eliad Peller <eliad@xxxxxxxxxx> wrote:
> On Tue, May 31, 2011 at 8:26 PM, Javier Cardona <javier@xxxxxxxxxxx> wrote:
>> On Mon, May 30, 2011 at 3:51 AM, Vivek Natarajan <vivek.natraj@xxxxxxxxx> wrote:
>>> On Wed, May 4, 2011 at 10:54 PM, Javier Cardona <javier@xxxxxxxxxxx> wrote:
>>>> Mesh beacons no longer use all-zeroes BSSID. Beacon frames for MBSS,
>>>> infrastructure BSS, or IBSS are differentiated by the Capability
>>>> Information field in the Beacon frame. A mesh STA sets the ESS and IBSS
>>>> subfields to 0 in transmitted Beacon or Probe Response management
>>>> frames.
>>>
>>> This breaks P2P mode as a P2P STA also sets the ESS and IBSS subfields
>>> to zero. Is there any other way to find if it is a mesh other than
>>> this check?
>>
>> Bummer. I guess that's a collision between WiFi Alliance and IEEE,
>> respectively the organizations standardizing P2P and 802.11s.
>> The 11s draft is pretty clear about that. I can consult the task
>> group and see if they have thought about this conflict.
>>
>>>> index fbf6f33..62e542a 100644
>>>> --- a/net/wireless/scan.c
>>>> +++ b/net/wireless/scan.c
>>>
>>>> @@ -407,7 +407,7 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
>>>>
>>>> res->ts = jiffies;
>>>>
>>>> - if (is_zero_ether_addr(res->pub.bssid)) {
>>>> + if (WLAN_CAPABILITY_IS_MBSS(res->pub.capability)) {
>>>> /* must be mesh, verify */
>>>
>>> Reverting the above change, makes P2P work. Any other better fix?
>>
>> We could check that the WLAN_CAPABILITY_IS_MBSS *and* that the bssid
>> matches the TA. Do you think that would work?
>>
> i guess you are referring to SA (rather than TA).
> in that case, this solution is not enough, as SA==bssid also holds
> true for the p2p probe responses (at least when a single vif is being
> used).
Yes, you are right, SA or Address 2 (11s changes the address field
definitions from DA, SA, BSSID to Address 1, 2 and 3). In mesh
management frames, Address 2 always equals Address 3. Is this also
the case for some P2P management frames?
> btw, i've already submitted some workaround for this issue:
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/70763
>
> in case we won't find a better solution...
OK. If the answer to my question above is yes, then I guess we'll
have to do it as you suggest. Thanks!
Javier
--
Javier Cardona
cozybit Inc.
http://www.cozybit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
