linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bruno randolf <bruno@thinktube.com>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: "Jouni Malinen" <j@w1.fi>,
	"John W. Linville" <linville@tuxdriver.com>,
	"Johannes Berg" <johannes@sipsolutions.net>,
	jirislaby@gmail.com, mickflemm@gmail.com,
	linux-wireless@vger.kernel.org,
	"Ivo van Doorn" <ivdoorn@gmail.com>,
	"Kishore Ramachandran" <kishore@winlab.rutgers.edu>,
	"Ivan Seskar" <Seskar@winlab.rutgers.edu>
Subject: Re: [PATCH] mac80211: enable IBSS merging
Date: Tue, 12 Feb 2008 11:00:00 +0900	[thread overview]
Message-ID: <200802121100.02259.bruno@thinktube.com> (raw)
In-Reply-To: <43e72e890802080122x67a1fed1s7e6193eea0559f16@mail.gmail.com>

On Friday 08 February 2008 18:22:52 Luis R. Rodriguez wrote:
> On Feb 6, 2008 10:58 PM, Jouni Malinen <j@w1.fi> wrote:
> > On Wed, Feb 06, 2008 at 03:10:35PM -0500, John W. Linville wrote:
> > > FWIW, that wouldn't be the first time we (i.e. Linux) chose to do
> > > something that did not completely comply with a standard.  If it
> > > interoperates with other equipment and is good for users, I don't
> > > think picky standard compliance is worthwhile.
> >
> > Sure, there are cases where this is reasonable.
> >
> > > Please note that I am not really taking a stand in favor of this ATM,
> > > only asserting that blind standard compliance is not a good reason
> > > to NAK it IMHO.
> >
> > In this case, standard compliance is certainly not the only concern I
> > have. I'm worried about interoperability with non-mac80211
> > implementations. If mac80211 were to hardcoded the BSSID for IBSS and
> > refuse to change it no matter what (i.e., behave against the IEEE 802.11
> > standard), IBSS would not interoperate with any other implementation if
> > the other implementation happens to be the creator of the IBSS..
>
> OK so you're saying that some people might actually expect that when
> using the same SSID and same channel in close vicinity they'd get
> separate BSSIDs generated? If so I don't see why people would expect
> this functionality as a feature, I think this is more of a problem
> than an expected result of how the standard is designed.
>
> > Same issues shows up (but in somewhat less frequent form) in an IBSS
> > splitting up and re-joining. In order to allow the STAs using other
> > implementation (no BSSID hacks) to join the IBSS, mac80211 will need to
> > be prepared to change the BSSID (or use some much more questionable
> > hacks to make sure it is always the mac80211-STA that wins in the
> > selection of which BSSID will survive.. ;-).
>
> How would the IBSS be split up to generate a new BSSID? If you are
> part of an IBSS and you don't see anyone generate a beacon between the
> random backoff time you simply generate it, but the BSSID would still
> be the same.

i think the point here is that we still need to be prepared to merge IBSS 
(i.e. switch to another BSSID when we receive a beacon with an older TSF) no 
matter how we generate our own BSSID in the first place. 

using a hash of the BSSID and channel would reduce the necessity to merge IBSS 
for mac80211 drivers but we still need to be able to join older IBSS from 
other drivers.

bruno



  reply	other threads:[~2008-02-12  2:00 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-18 12:52 [PATCH] mac80211: enable IBSS merging Bruno Randolf
2008-01-20 10:17 ` Luis R. Rodriguez
2008-01-20 10:43   ` Ivo van Doorn
2008-01-21  1:52     ` bruno randolf
2008-01-21 16:05       ` Ivo van Doorn
2008-01-22 19:47         ` Luis R. Rodriguez
2008-01-22 19:54           ` Ivo van Doorn
2008-01-22 20:32             ` Luis R. Rodriguez
2008-01-22 20:51               ` Ivo van Doorn
2008-01-23  1:59               ` [ath5k-devel] " bruno randolf
2008-01-22 23:16             ` Adam Baker
2008-01-22 23:25               ` Ivo van Doorn
2008-01-23 14:49     ` Johannes Berg
2008-01-24  5:51       ` bruno randolf
2008-01-21  1:57   ` bruno randolf
2008-01-23 14:48 ` Johannes Berg
2008-01-23 17:22   ` Dan Williams
2008-01-24  3:49     ` bruno randolf
2008-01-24  3:26   ` bruno randolf
2008-01-24 16:55     ` Johannes Berg
2008-01-25  8:01       ` bruno randolf
2008-02-02 23:22         ` Luis R. Rodriguez
2008-02-05  1:50           ` bruno randolf
2008-02-05  1:56             ` Luis R. Rodriguez
2008-02-06 10:01             ` Johannes Berg
2008-02-06  4:34           ` Jouni Malinen
2008-02-06 18:33             ` Luis R. Rodriguez
2008-02-06 20:10               ` John W. Linville
2008-02-07  3:58                 ` Jouni Malinen
2008-02-08  9:22                   ` Luis R. Rodriguez
2008-02-12  2:00                     ` bruno randolf [this message]
2008-02-15  1:06                       ` Luis R. Rodriguez
2008-02-15  1:40                         ` bruno randolf
2008-02-07  3:52               ` Jouni Malinen
2008-02-08  9:10                 ` Luis R. Rodriguez
2008-01-24  5:43   ` bruno randolf
2008-01-24  8:51     ` Kalle Valo
2008-01-24 14:27       ` Johannes Berg
2008-01-24 14:30     ` Johannes Berg
2008-01-25  6:16       ` bruno randolf
  -- strict thread matches above, loose matches on Subject: below --
2008-02-05 11:08 [PATCH 2/2] " Johannes Berg
2008-02-06  2:49 ` [PATCH] " Bruno Randolf
2008-02-06 23:52   ` Johannes Berg
2008-02-08  9:25     ` Luis R. Rodriguez
2008-02-12  3:25     ` bruno randolf
2008-02-12  9:50       ` Johannes Berg
2008-02-14  6:19         ` bruno randolf
2008-02-14 14:12           ` Johannes Berg
2008-02-12  9:52       ` Johannes Berg
2008-02-14 10:19         ` bruno randolf
2008-02-08  9:41 Joerg Pommnitz
2008-02-15 15:09 [PATCH 3/3] " Johannes Berg
2008-02-16  2:29 ` [PATCH] " Bruno Randolf
2008-02-17  9:11   ` Johannes Berg
2008-02-18  1:42     ` bruno randolf
2008-02-18 11:15       ` Johannes Berg
2008-02-18  2:03     ` bruno randolf
2008-02-18 11:16       ` 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=200802121100.02259.bruno@thinktube.com \
    --to=bruno@thinktube.com \
    --cc=Seskar@winlab.rutgers.edu \
    --cc=ivdoorn@gmail.com \
    --cc=j@w1.fi \
    --cc=jirislaby@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=kishore@winlab.rutgers.edu \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mcgrof@gmail.com \
    --cc=mickflemm@gmail.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;
as well as URLs for NNTP newsgroup(s).