Re: [manet-dlep-rg] 802.11 Adhoc scenario

Teco Boot <> Fri, 07 March 2014 00:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 09EF91A0186 for <>; Thu, 6 Mar 2014 16:10:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q-y2g7jNJodu for <>; Thu, 6 Mar 2014 16:09:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 67A321A014E for <>; Thu, 6 Mar 2014 16:09:54 -0800 (PST)
Received: by with SMTP id w62so4118213wes.0 for <>; Thu, 06 Mar 2014 16:09:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=J8jFpj2EklC7offo2W2oGC9I4XInHBJN/qGo2+V6LBE=; b=lgi5t2rA9oFIDmFbhUfC12gu7mzI4rEdLjwmHZjmxnLzQlLezvcPsKXmjaWyTdzx/G 8ueWMIkStpq84PrTKI+o9I6p70LLc3AgNV3Q6kDgMinKHrbTNZfLQWYkOs5ngSbuTrm1 4ruLWiEEKNbwQ6Fk3+XeqQjqA5qKXBT8wgcQyZyaijOasA0cHOCs36TvBajXa/Ok9dNd o/LJ3levySbM2GG/gTLeyqpE8dhrb2CNMHG52hTtxIdU20/pua+o4UczIxRKsPAhDfSY Mzs3H+q5tuoXDsrV1Srz7qGd07i/oYB9FvzSc/Oke0HPe3sOsXbqt1pep65zPLYBvZPG GtcQ==
X-Gm-Message-State: ALoCoQlJ78m7ne+0yWtVq1273bMIwTjCmzA3Ao8jJgjmIw0uVgMcydSu4P/xD4CfmoqL/nKDe6zT
X-Received: by with SMTP id g13mr14593788wjq.42.1394150990287; Thu, 06 Mar 2014 16:09:50 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id ux5sm515490wjc.6.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 16:09:49 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Teco Boot <>
In-Reply-To: <>
Date: Fri, 7 Mar 2014 01:09:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <1D05E36C-A91D-415B> <> <> <>
To: Henning Rogge <>
X-Mailer: Apple Mail (2.1874)
Cc: "DLEP Research Group, \(\)" <>, John Dowdell <>, Rick Taylor <>, Stan Ratliff <>
Subject: Re: [manet-dlep-rg] 802.11 Adhoc scenario
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DLEP Radio Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Mar 2014 00:10:00 -0000

The spec was never broken. Drivers were buggy.

.11s has a nice airtime metric :-)


Op 6 mrt. 2014, om 19:33 heeft Henning Rogge <> het volgende geschreven:

> Not sure I want to pretend 802.11s fixed anything...
> Henning
> On Mar 6, 2014 6:30 PM, "John Dowdell" <> wrote:
> All
> I am going to show my ignorance here, but is this 'feature' fixed in 802.11s do you know?
> Regards
> John
> On Thursday, March 6, 2014, Teco Boot <> wrote:
> Stan, we know about the buggy BSSID coalescing. Bugs are solved in most drivers. Other drivers simply disable IBBS (ad hoc) mode.
> In most WLAN ad hoc networks, BSSID is generated as pseudo-random on SSID and optionally the channel ID. Or configured manually. Also, many WLAN ad hoc implementations deviate a little bit from the 802.11 standard by disabling management frames at all. The military WLAN based radio’s deviate a little bit more than the community networks, by adjusted drivers, firmware and RF circuits.
> Teco
> Op 5 mrt. 2014, om 23:12 heeft Stan Ratliff (sratliff) <> het volgende geschreven:
> > I was just downstairs, smoking a cigarette, when I remembered one of the basic scenarios that stops people from using 802.11 adhoc for really mobile deployments. Thought I'd offer it up as some rationale for my earlier statement regarding 802.11 adhoc. I wish I had the lightening recall and scathing keyboard abilities of some in the MANET working group, but alas, the years, the beer, the medical conditions, and the prescription drugs that go with the medical conditions have slowed the memory access somewhat… ;-)
> >
> > I've heard this referred to as the "Split-BSSID Problem", but I don't know if that's the official term, so let me lay out the scenario. While I don't put interval times in my scenario, there on the order of a small number of seconds. That being said, the scenario goes like this:
> >
> > 1) I configure up 4 802.11 adhoc radios and associated gear for a demo. I configure the radios with 802.11 BSSID "Foo". The gear and the software is works great; everyone can talk to everyone else, it looks beautiful. Now, all I need to do is to get some people for the demo, which uses the radios in a man-packable fashion. Oh, by the way, the demo is at some remote location (let's say Honolulu, because I've always liked the beach). So, I power down the gear, pack it up, and…
> >
> > 2) I get Henning, Teco, Rick, and Stan (after all, I'm going to Honolulu) to do the demo. Once we're down around Waikiki Beach, I hand out the gear (it's still powered off, BTW).
> >
> > 3) With the gear powered off, Henning and Teco walk to the right; Rick and Stan walk to the left (non-smokers in one direction, smokers in the other). They stroll along the beach, until they get quite a distance from each other (out of 802.11 radio range).
> >
> > 4) Since it's still early, Henning and Teco, as well as Rick and Stan, get a coffee at the Starbucks (there's one on every corner), and Rick and Stan light up a cigarette (nasty habit). At the appointed time for the demo,
> >
> > 5) Stan turns his radio and gear on. So does Teco. Stan's radio BEACONs with "Foo" as the BSSID. So does Teco's radio. They don't find anyone. Both radios think "Well, I'm the first guy here". So Stan's radio adds a "magic number", which is really a hash of its MAC address, to the BEACON. Teco's radio computes a different magic number (since he has a different MAC), and does the same thing. A second or two later,
> >
> > 6) Rick turns his radio on. So does Henning. Rick's radio BEACONs, but sees Stan's radio BEACON as well. So Rick's radio basically says "Oh, cool. There's someone here. I'll just take his magic number, and join the BSSID". So Stan's radio and Rick's radio are chatting away. Henning's radio BEACONs as well, and sees Teco's radio. Henning's radio also says "Cool! Someone's already here", and adopts Teco's magic number. Henning's radio and Teco's radio are also chatting away with each other.
> >
> > 7) Now, the "mobility scenario" starts. Rick and Stan start walking back down the beach, toward the starting point. Henning and Teco do the same. Before long, all 4 come into radio range with each other. But since they've got different "magic numbers", they *WILL NOT* establish one big, happy, 4-person BSSID. Stan's radio can't talk to either Henning or Teco; neither can Rick's. The demo is starting to go spectacularly wrong…
> >
> > The only way out of this to power off two of the radios - well, the *right* two radios (either Stan's and Rick's; OR Teco's and Henning's), and power them back up. Then, they'll join the existing adhoc BSSID, and everyone will be happy. The moral of the story? Every radio that participates in an adhoc BSSID MUST be powered up whilst "in range". Otherwise, said radio won't be able to ultimately join the BSSID, even though they're configured correctly. IMO, it's a flaw (and a BIG one) in the adhoc portion of the 802.11 spec.
> >
> > Thanks for reading and considering my little story… ;-)
> >
> > Regards,
> > Stan
> > _______________________________________________
> > manet-dlep-rg mailing list
> >
> >
> _______________________________________________
> manet-dlep-rg mailing list