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

[Joe Macker <[e-mail]>]

Cool (especially Waikiki), that;s old one but a goodie as they say!
I think non-spec workarounds exist (dependent on the hardward/software driver).

Early on in 802.11 spec there was this idea a coalesce algorithm (like always move towards the highest BSSID you hear in your neighborhood) in early 2000s I remember some systems worked this way (not saying the spec ever said anything about it).  Certainly even when manufacturers did something like this there was a convergence time and this was reported in a few older research papers. 

I don’t think it was ever included because everyone in the committee had different ideas of how to do it? (sound familiar).

—— not a solution to the adhoc formation problem but-----
I think I remember openWRT having both some form of convergence setting (pick older BSSID you hear so allowing for eventual convergence) and some way to override this manually when planning say a community network. Maybe not. I assume Henning would know more given experience that hardware,etc.

Even though it may not be well documented I thought there was an "iwconfig command" for overriding the BSSID and also a convergence algorithm that still works in that deployment hardware if chosen.

I agree not being in the spec has caused people and systems to develop work arounds and the very least makes for inconsistent features.
---------------------------

On Mar 5, 2014, at 5:12 PM, Stan Ratliff (sratliff) <[e-mail]> wrote:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg