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

Henning Rogge <hrogge@gmail.com> Thu, 06 March 2014 18:33 UTC

Return-Path: <hrogge@gmail.com>
X-Original-To: manet-dlep-rg@ietfa.amsl.com
Delivered-To: manet-dlep-rg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F961A0290 for <manet-dlep-rg@ietfa.amsl.com>; Thu, 6 Mar 2014 10:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCWfzsXT5-LL for <manet-dlep-rg@ietfa.amsl.com>; Thu, 6 Mar 2014 10:33:17 -0800 (PST)
Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 370D51A0291 for <manet-dlep-rg@ietf.org>; Thu, 6 Mar 2014 10:33:05 -0800 (PST)
Received: by mail-qc0-f180.google.com with SMTP id x3so3467102qcv.11 for <manet-dlep-rg@ietf.org>; Thu, 06 Mar 2014 10:33:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vxn1XmL2dPI4TqbBQGA1ZLw0fBXjpUdUGdV3ZJSznKM=; b=p6joJbSg1hgWNidly5HCkgGS5BGTqZ84rNfifPw/tbe3tRGZA+qXLh39Y88cr0mB0w itV0UFnCbsP2r5ymUA7QRIIgN2f0sl/6XH+6m3+0LkbLS+e3Xw5yx+u0MS7AT6xie3D/ GY3tIS74LBHKMoRw+dltAWxrjLuFTNA1hID5ODkVvHnoYqHXi/FyqZBKBMNkB/nNgKXZ ZpM+MHc7aB86xiSXZpUVKv++Zix6bZpy2SPaOAQK1rXRT3kfpfI8PTMHfWxKoNyB3LR7 s2D+AK2h4IcFQxQVi9lVg21HcvSPQ0bsL4giJxbS4sJkAcXqMUFc06pMUpXOhGWi/rtz scKQ==
MIME-Version: 1.0
X-Received: by 10.229.98.135 with SMTP id q7mr9769267qcn.12.1394130780998; Thu, 06 Mar 2014 10:33:00 -0800 (PST)
Received: by 10.224.130.2 with HTTP; Thu, 6 Mar 2014 10:33:00 -0800 (PST)
Received: by 10.224.130.2 with HTTP; Thu, 6 Mar 2014 10:33:00 -0800 (PST)
In-Reply-To: <CAEhHF6V7u7VSXytqhiLbgH3GO85ghzV=R4S-OpOPuukkHQ05CQ@mail.gmail.com>
References: <38A5475DE83986499AEACD2CFAFC3F98FA6C34C0@tss-server1.home.tropicalstormsoftware.com> <480A632F-CB9E-4A62-ACDA-521C1A899049@inf-net.nl> <CAGnRvuqL8z+P5BJP-duyQo2BnTSpnkv7nDnOEdAQ1RfdXu7r+Q@mail.gmail.com> <38A5475DE83986499AEACD2CFAFC3F98FA6C4B60@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98FA6C56BA@tss-server1.home.tropicalstormsoftware.com> <CAGnRvuotok8UC-=i9RU8RvAv_wcv1DE3ubRLqibWeDLF6KRuDA@mail.gmail.com> <FB821471-E223-41BE-8D38-24C54B2B92C5@cisco.com> <CAGnRvupAoaLtvsHh6TLXvxsBnmrLMtPCZ-VKuxR=gVPxnchWDQ@mail.gmail.com> <67373A27-5AB2-47D3-B543-C0EB72D0AD7C@cisco.com> <CAGnRvuqHknFWoLyv5RjM3OcJ+g4WsRTphMH8d9wLQV+m+J+6uw@mail.gmail.com> <DBAE1DE6-0929-40B3-A044-AF3560829F16@cisco.com> <CAGnRvuo4qeesXZV7Xy6Uy7X+UVRw3u4vPZTC9U26uVX_Qx78Nw@mail.gmail.com> <4AD4566B-72EA-476A-9F3B-D8CDFC6F20C4@cisco.com> <CAGnRvur=C6ay0fT1cmOv79SkR7DgBFEOo3oTo2fb16OS2JCJag@mail.gmail.com> <829C05C9-B357-4F0C-8EA9-34F8182D3F5F@cisco.com> <1D05E36C-A91D-415B-85F4-CEC8207E06D2@cisco.com> <679073E8-22C1-4423-AB98-DA25C1C11694@inf-net.nl> <CAEhHF6V7u7VSXytqhiLbgH3GO85ghzV=R4S-OpOPuukkHQ05CQ@mail.gmail.com>
Date: Thu, 06 Mar 2014 18:33:00 +0000
Message-ID: <CAGnRvurQKEF+jkYHM3NyS_QLCNLpYmAkXYXMup+nmxm3xSEm8A@mail.gmail.com>
From: Henning Rogge <hrogge@gmail.com>
To: John Dowdell <john.dowdell.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="001a113452e0f8e2ca04f3f45d30"
Archived-At: http://mailarchive.ietf.org/arch/msg/manet-dlep-rg/3gemUUgNkOmJsARfya0LZXaUEDA
Cc: "DLEP Research Group, (manet-dlep-rg@ietf.org)" <manet-dlep-rg@ietf.org>, Teco Boot <teco@inf-net.nl>, Rick Taylor <rick@tropicalstormsoftware.com>, Stan Ratliff <sratliff@cisco.com>
Subject: Re: [manet-dlep-rg] 802.11 Adhoc scenario
X-BeenThere: manet-dlep-rg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DLEP Radio Group <manet-dlep-rg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet-dlep-rg/>
List-Post: <mailto:manet-dlep-rg@ietf.org>
List-Help: <mailto:manet-dlep-rg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 18:33:21 -0000

Not sure I want to pretend 802.11s fixed anything...

Henning
On Mar 6, 2014 6:30 PM, "John Dowdell" <john.dowdell.ietf@gmail.com> 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 <teco@inf-net.nl> 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) <
>> sratliff@cisco.com> 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@ietf.org
>> > https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>>
>> _______________________________________________
>> manet-dlep-rg mailing list
>> manet-dlep-rg@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>>
>