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

John Dowdell <> Thu, 06 March 2014 18:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 50B4E1A01CC for <>; Thu, 6 Mar 2014 10:30:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n3nfxASLYzoj for <>; Thu, 6 Mar 2014 10:30:53 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c03::22c]) by (Postfix) with ESMTP id 65BF41A0051 for <>; Thu, 6 Mar 2014 10:30:53 -0800 (PST)
Received: by with SMTP id lf12so3003358vcb.17 for <>; Thu, 06 Mar 2014 10:30:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JxmhaovnOnlnR1g4POe4MFdjmDi4Tss+WyhwLIpMUQs=; b=bmdE/UYa4bOFkqeDn07zw61HjaqceGrExvhITFgmdZGd6Sq74E0LIdJEZ2dH5455At V2FP5nJyhRQM0B85t0MR0HZkbaSO3mrJB3HPamQ1g6ddm5oi8YPyaAit/0IZTyB7VTIY JnFKExTB9W6HUjEaVIXlXCc2bbOxWlvHfm1enfCa3/hBCfXTalHTcq/CRs0C4bPLBWhT 5p69P16a6qH2ADxsbD1fCWK1ExCyUZtjwF8tj/6jLELxMRyhmC1dRvSZ6p/Lmi/Wp1Y/ z9SzARAbXAUoElcJ+igO41MZOEOJ2mZILGS5P+IRtYRQjIvvpHMyecenTVgatBUvDi0u 8JSQ==
MIME-Version: 1.0
X-Received: by with SMTP id hy10mr259089veb.52.1394130649213; Thu, 06 Mar 2014 10:30:49 -0800 (PST)
Received: by with HTTP; Thu, 6 Mar 2014 10:30:49 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 6 Mar 2014 18:30:49 +0000
Message-ID: <>
From: John Dowdell <>
To: Teco Boot <>
Content-Type: multipart/alternative; boundary=089e0158bd641def7b04f3f456ff
Cc: "DLEP Research Group, \(\)" <>, Henning Rogge <>, 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: Thu, 06 Mar 2014 18:30:59 -0000


I am going to show my ignorance here, but is this 'feature' fixed in
802.11s do you know?


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) <<javascript:;>>
> 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
> > <javascript:;>
> >
> _______________________________________________
> manet-dlep-rg mailing list
> <javascript:;>