mesh beaconing questions

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

Hi,

The Draft states that beacons may be sent either as defined for IBSS or
as defined for infrastructure mode.

I have a few questions, some of which are related to our implementation
and others which are related to the Draft.

1. Are we going to let drivers choose which mode to use? Should they
indicate that somehow so userspace knows? Or are we going to make this
configurable? Can all hardware support both modes? (the last question
probably ties in with the next)

2. The Draft states to use either procedures 11.1.2.2 (IBSS) or 11.1.2.1
(infrastructure). It is easy to "port" 11.1.2.1 to mesh, but 11.1.2.2
reads like this:

--- >% ---
[...]

At each TBTT, the STA shall:

[...]

 (d) Cancel the remaining random delay and the pending beacon
     transmission, if a beacon arrives from the IBSS of which the STA is
     a member before the random delay timer has expired, at which time
     the ATIM backoff timer shall resume decrementing.
[...]
--- %< ---

However, I feel that pointing from the mesh amendement to something
rather IBSS specific is not well defined. This clause doesn't
"obviously" port to mesh since the BSSID is left zeroed in mesh! But the
draft doesn't change 11.1.2.2 either to adjust for this difference.

Hence, I think the draft needs to be expanded to modify 11.1.2.2 to
explain under which circumstances an MP shall cancel its beacon if it
opts to use IBSS-like beaconing.

I think the only useful thing is to require it to look at the mesh IEs,
but that is not implementable with existing hardware, at least not
without firmware changes. I could probably do it in Broadcom firmware
fairly easily...

So now I've probably answered my first question implicitly because I
pointed out how I think using IBSS-like beaconing isn't even
well-defined ;)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]