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

Teco Boot <teco@inf-net.nl> Thu, 06 March 2014 09:59 UTC

Return-Path: <teco@inf-net.nl>
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 F3AAA1A019A for <manet-dlep-rg@ietfa.amsl.com>; Thu, 6 Mar 2014 01:59:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9yvVNVT0sed for <manet-dlep-rg@ietfa.amsl.com>; Thu, 6 Mar 2014 01:58:58 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BADDF1A019D for <manet-dlep-rg@ietf.org>; Thu, 6 Mar 2014 01:58:57 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id m15so377012wgh.15 for <manet-dlep-rg@ietf.org>; Thu, 06 Mar 2014 01:58:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=ksMtyQEHwJDUrnqTw319z8N4MN6eteqOKUCX3Al+OIs=; b=ErRuCOPDnEhoEnWaC4fYnnaogykRrf/+hx3CVTFCHJzJgQv840S0vGrVLeqMnjvpnm 3AAuBeWEo07e3UOBtCjTBN4utmCoueWDp+DIF0lgS0smGvFESoQuiJvem360u4vVc1Gd 4SzEgSLQ6U1jE4nJtPGPfVURgoUll++sLT4ssf8dZRQzI+cSJsfH2nWK6z81B7VB1cit Udm76gM5f12YS8Ur/kjPad0PM6sx93+FfJ7DdpggAuKpn9+Eb2o3BN+BvUq66re2Lppg wMq+SqY+zg8QiumpyBhsK65lDQymA4z1qQI/sV7HNYtq/0TGTZ8TaHUfgnY3gCGmTF6R axEg==
X-Gm-Message-State: ALoCoQl768WmbZL+BJQfYqKidT9bCX9xCi44sppbPb0vVtMjPCfkpfZXmSJS9hSm9Mv5Lugs0OaG
X-Received: by 10.194.121.129 with SMTP id lk1mr8473792wjb.80.1394099933353; Thu, 06 Mar 2014 01:58:53 -0800 (PST)
Received: from dhcp-a727.meeting.ietf.org (dhcp-a727.meeting.ietf.org. [31.133.167.39]) by mx.google.com with ESMTPSA id az1sm14383572wjb.11.2014.03.06.01.58.52 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 01:58:52 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <1D05E36C-A91D-415B-85F4-CEC8207E06D2@cisco.com>
Date: Thu, 6 Mar 2014 10:58:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <679073E8-22C1-4423-AB98-DA25C1C11694@inf-net.nl>
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>
To: Stan Ratliff <sratliff@cisco.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet-dlep-rg/q0c_myT7ATfxiYeG8YvYaCN5nqE
Cc: "DLEP Research Group, \(manet-dlep-rg@ietf.org\)" <manet-dlep-rg@ietf.org>, Henning Rogge <hrogge@gmail.com>, Rick Taylor <rick@tropicalstormsoftware.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 09:59:01 -0000

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