Linux wireless drivers development
 help / color / mirror / Atom feed
From: "Javier Cardona" <javier@cozybit.com>
To: "Johannes Berg" <johannes@sipsolutions.net>
Cc: "Luis Carlos Cobo" <luisca@cozybit.com>,
	linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: mesh beaconing questions
Date: Tue, 4 Mar 2008 21:37:29 -0800	[thread overview]
Message-ID: <445f43ac0803042137n6ce996f4radd58d3104fb49e1@mail.gmail.com> (raw)
In-Reply-To: <1204034825.13162.233.camel@johannes.berg>

Hi Johannes,

>  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)

Beaconing and synchronization are the two areas that are still
actively debated at TGs, and they are somewhat dependent (
http://odysseus.ieee.org/cs.html?charset=iso-8859-1&url=http%3A//mentor.ieee.org/802.11/public-file/07/11-07-2853-00-000s-functional-interdependences.ppt&qt=url%3Amentor.ieee.org/802.11+||+jarkko+kneckt&col=mentor&n=2&la=en
). I would not invest much time in trying to support both modes at
this time.

That said, if things stay as they are now, we would have to make that
configurable (only if the driver supports both beaconing modes, of
course).

> (...)
> 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.

Agreed.

> I think the only useful thing is to require it to look at the mesh IEs,

... and path selection method and metric.

> but that is not implementable with existing hardware, at least not
> without firmware changes.

Needing firmware changes is a problem for o11s, but not for TGs:
there will be other firmware (and maybe hardware) changes required to
implement the standard.  o11s challenge is to do as much as possible
with commodity hardware, and doing IBSS beaconing with null BSSID
seems like an OK compromise.  Every once in a while and MP may cancel
a beacon transmission because it receives a beacon from a different
mesh:  that's not such a big deal.

Cheers,

Javier

PS.  BTW, you should attend the IEEE meetings.  Really!

-- 
Javier Cardona
cozybit Inc.

  parent reply	other threads:[~2008-03-05  5:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-26 14:07 mesh beaconing questions Johannes Berg
2008-02-26 15:42 ` Dan Williams
2008-02-26 15:54   ` Johannes Berg
2008-03-05  5:37 ` Javier Cardona [this message]
2008-03-05  9:35   ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=445f43ac0803042137n6ce996f4radd58d3104fb49e1@mail.gmail.com \
    --to=javier@cozybit.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luisca@cozybit.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox