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

[Henning Rogge <[e-mail]>]

And "iwconfig" has been  deprecated for a number of years and have been
replaced by the much more powerful/versatile "iw" command.

Henning
On Mar 6, 2014 10:43 PM, "Joe Macker" <[e-mail]> wrote:

> We did the same in early experiments  many moons ago by fixing BSSID.
> As I was mentioning I think iwconfig supports that directly.
>
> -Joe
>
> On Mar 6, 2014, at 2:40 AM, Henning Rogge <[e-mail]> wrote:
>
> > Damned Stan...
> >
> > I read your long post and decided "I will formulate a great argument
> > when I got a shower"... and I think I have found a good argument how
> > to resolve the problem, unfortunately its self-defeating.
> >
> > I somehow managed to convince me that it might be better to change the
> > mac address of the wifi card and not the mac address of the routers
> > interface, because that is more along the line "the router
> > controls/configures the radio". Consider the request for the "mac" TLV
> > in the first peer discovery dropped.
> >
> > About the Adhoc stuff, I think you underestimate the amount of work
> > the linux community did with their wifi-stack in the last 5 years.
> > IBSS/Adhoc mode is normally working very well, I have not heard about
> > huge "split net" problems for quite some time.
> >
> > Of course most community networks solved this problem even earlier by
> > just setting a fixed BSSID on all nodes.
> >
> > Henning Rogge
> >
> > On Wed, Mar 5, 2014 at 10:57 PM, Joe Macker <[e-mail]> wrote:
> >> 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
> >>
>
>