Re: mesh beaconing questions

[Dan Williams <dcbw@redhat.com>]

On Tue, 2008-02-26 at 15:07 +0100, Johannes Berg wrote:
> 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:

Next question, more relevant to how this affects the user:

What's the meaningful difference between these two choices?  When would
you use one and when would you use the other?  Should the user (ie, a
user of something like NetworkManager) care whether a particular node is
doing IBSS or infrastructure beacons?

Dan

> --- >% ---
> [...]
> 
> 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