Jeff Lieberman HEY

Hi Jeff,
Jeff, its me airhead. I was wondering if you would look at thread 'WET11 Ad
Hoc 'dated 12-10. I have been discussing this for a fews days with CRB and
need the masters opinion. All others input welcome.

On Tue, 14 Dec 2004 15:47:48 -0600, "Airhead"
<(E-Mail Removed)> wrote:

>Jeff, its me airhead.

Now what?

>I was wondering if you would look at thread 'WET11 Ad
>Hoc 'dated 12-10. I have been discussing this for a fews days with CRB and
>need the masters opinion. All others input welcome.

Well, you're doing fine at prying the numerical details out of Mr.
CRB. I can usually humiliate the person asking and extract the
necessary details in about two replies. You're on #5 and gaining.
Please read any of my replies for clues on methods of intimidating and
prying loose information from people who suffer from FON (fear of
numbers). You also missed several opportunities to scream at him for
paraphrasing MAC addresses and excessively trimming diagnostic output.

Incidentally, I don't think that Ad-Hoc uses "random" MAC addresses as
you claim. It uses either the MAC address of the WET11 or the cloned
address of the connected ethernet card if so configured.

The last message:
(E-Mail Removed)
seems to show that he's done all the right tests, tried all
permutations of configurations, disabled the firewall, tried other
computahs, and tested the WET11's with an access point. I can't think
of anything more to try with the two WET11's.

Well, maybe not. See:
http://www.oreillynet.com/pub/a/wire.../11/wet11.html
in the section starting with "wet 11 useless". Are there any extra
devices (hub or switch) between the WET11 and the computah?

My best suggestion is to introduce a 3rd (or 4th) Ad-Hoc radio into
the puzzle and test it with either or both WET11. Preferably, it
should NOT be a WET11 to take possible firmware issues out of the
picture. It should also be on an unrelated computah to avoid any
possible computer related configuration issues. Try various
combinations of computahs and wireless bridges. Maybe a pattern or
culprit will be evident. Anyway, this is your thread. You deal with
it.


--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831.336.2558 voice http://www.LearnByDestroying.com
# (E-Mail Removed)
# (E-Mail Removed) AE6KS

"> >Jeff, its me airhead.
>
> Now what?

You have a great sense of humor!

>
> >I was wondering if you would look at thread 'WET11 Ad
> >Hoc 'dated 12-10. I have been discussing this for a fews days with
CRB and
> >need the masters opinion. All others input welcome.
>
> Well, you're doing fine at prying the numerical details out of Mr.
> CRB. I can usually humiliate the person asking and extract the
> necessary details in about two replies. You're on #5 and gaining.
> Please read any of my replies for clues on methods of intimidating
and
> prying loose information from people who suffer from FON (fear of
> numbers). You also missed several opportunities to scream at him
for
> paraphrasing MAC addresses and excessively trimming diagnostic
output.

I am practicing on this.
>
> Incidentally, I don't think that Ad-Hoc uses "random" MAC addresses
as
> you claim. It uses either the MAC address of the WET11 or the
cloned
> address of the connected ethernet card if so configured.

Well, I didnt quite understand it either, maybe you can clairfiy it.
I got it from 7.1.3.3.3 of the 802.11 1999 standards.

BSSID field
"The value of this field in an IBSS is a locally administered IEEE MAC
address formed from
a 46 bit random number generated according to the procedure in 11.1.3.
This mechanism
is used to provide a high propability of selecting a unique BSSID."

Reading 11.1.3 even makes it more confusing, but it says it generates
th lasr 46 bits randomly
an the remaing bits are as in 802 1990.

So, I dont understand this, maybe you can explain it to me so I dont
go telling other people
foolish stuff like this.

>
> The last message:
> (E-Mail Removed)
> seems to show that he's done all the right tests, tried all
> permutations of configurations, disabled the firewall, tried other
> computahs, and tested the WET11's with an access point. I can't
think
> of anything more to try with the two WET11's.
>
> Well, maybe not. See:
> http://www.oreillynet.com/pub/a/wire.../11/wet11.html
> in the section starting with "wet 11 useless". Are there any extra
> devices (hub or switch) between the WET11 and the computah?
>
> My best suggestion is to introduce a 3rd (or 4th) Ad-Hoc radio into
> the puzzle and test it with either or both WET11. Preferably, it
> should NOT be a WET11 to take possible firmware issues out of the
> picture. It should also be on an unrelated computah to avoid any
> possible computer related configuration issues. Try various
> combinations of computahs and wireless bridges. Maybe a pattern or
> culprit will be evident. Anyway, this is your thread. You deal
with
> it.

Thanks, I was going to give it to your for Christmas.



>
>
> --
> # Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
> # 831.336.2558 voice http://www.LearnByDestroying.com
> # (E-Mail Removed)
> # (E-Mail Removed) AE6KS

"Airhead" <(E-Mail Removed)> wrote in message
news:41c01f63$0$800$(E-Mail Removed). ..
>
>>
>> Incidentally, I don't think that Ad-Hoc uses "random" MAC addresses
> as
>> you claim. It uses either the MAC address of the WET11 or the
> cloned
>> address of the connected ethernet card if so configured.
>
> Well, I didnt quite understand it either, maybe you can clairfiy it.
> I got it from 7.1.3.3.3 of the 802.11 1999 standards.
>
> BSSID field
> "The value of this field in an IBSS is a locally administered IEEE MAC
> address formed from
> a 46 bit random number generated according to the procedure in 11.1.3.
> This mechanism
> is used to provide a high propability of selecting a unique BSSID."

You read correctly. The MAC addresses crb listed are locally administered,
as required by this clause (the giveaway is that the first byte is 0x02). In
an infrastructure network, the MAC of the AP is the BSSID - but the AP "is"
the network, in the sense that it is not a client and it is the gate to the
distribution system. In an ad-hoc network, no client "is the network in this
way, and a BSSID is invented to distinguish the "net" from the participating
clients.

It seems to me that in crb's case, both clients are trying to start the
ad-hoc net. Only one station should generate a BSSID, others should be
trying to join the net if it exists. Joiners should use their own MAC
addresses.

I'm not completely clear on the details, but in an IBSS any station can
generate a beacon, and in fact multiple stations can issue a beacon
concurrently. A client trying to join passively scans - i.e., first listens
for one or more beacons from *some* station, with the desired SSID - or else
actively scans (sends a probe with the desired SSID and waits for a reponse
from any station). If a beacon or a probe response is received from any
station in the IBSS - doesn't matter which - the joiner now knows the BSSID.
Since any station can beacon or respond to probes, the BSSID should not be
associated with any particular one. Hence the randomized
locally-admininstered MAC.

I don't know if there is a config issue or not. But it does sound like the
second station is not trying to join, it's trying to start a net. Try
bringing one station up first, then the other. Maybe if they both start at
the same time, they both probe and get no response, so decide to create the
net. Or maybe one has to somehow be configured to only be a joiner. How this
is done is an implementation detail not addressed in the standard.

>
> Reading 11.1.3 even makes it more confusing, but it says it generates
> th lasr 46 bits randomly
> an the remaing bits are as in 802 1990.
>
> So, I dont understand this, maybe you can explain it to me so I dont
> go telling other people
> foolish stuff like this.
>
>>
>> The last message:
>> (E-Mail Removed)
>> seems to show that he's done all the right tests, tried all
>> permutations of configurations, disabled the firewall, tried other
>> computahs, and tested the WET11's with an access point. I can't
> think
>> of anything more to try with the two WET11's.
>>
>> Well, maybe not. See:
>> http://www.oreillynet.com/pub/a/wire.../11/wet11.html
>> in the section starting with "wet 11 useless". Are there any extra
>> devices (hub or switch) between the WET11 and the computah?
>>
>> My best suggestion is to introduce a 3rd (or 4th) Ad-Hoc radio into
>> the puzzle and test it with either or both WET11. Preferably, it
>> should NOT be a WET11 to take possible firmware issues out of the
>> picture. It should also be on an unrelated computah to avoid any
>> possible computer related configuration issues. Try various
>> combinations of computahs and wireless bridges. Maybe a pattern or
>> culprit will be evident. Anyway, this is your thread. You deal
> with
>> it.
>
> Thanks, I was going to give it to your for Christmas.
>
>
>
>>
>>
>> --
>> # Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
>> # 831.336.2558 voice http://www.LearnByDestroying.com
>> # (E-Mail Removed)
>> # (E-Mail Removed) AE6KS
>

"gary" <(E-Mail Removed)> wrote in message
news:eZ7wd.40236$(E-Mail Removed). com...
>
> "Airhead" <(E-Mail Removed)> wrote in message
> news:41c01f63$0$800$(E-Mail Removed). ..
> >
> >>
> >> Incidentally, I don't think that Ad-Hoc uses "random" MAC addresses
> > as
> >> you claim. It uses either the MAC address of the WET11 or the
> > cloned
> >> address of the connected ethernet card if so configured.
> >
> > Well, I didnt quite understand it either, maybe you can clairfiy it.
> > I got it from 7.1.3.3.3 of the 802.11 1999 standards.
> >
> > BSSID field
> > "The value of this field in an IBSS is a locally administered IEEE MAC
> > address formed from
> > a 46 bit random number generated according to the procedure in 11.1.3.
> > This mechanism
> > is used to provide a high propability of selecting a unique BSSID."
>
> You read correctly. The MAC addresses crb listed are locally administered,
> as required by this clause (the giveaway is that the first byte is 0x02).
In
> an infrastructure network, the MAC of the AP is the BSSID - but the AP
"is"
> the network, in the sense that it is not a client and it is the gate to
the
> distribution system. In an ad-hoc network, no client "is the network in
this
> way, and a BSSID is invented to distinguish the "net" from the
participating
> clients.
>
> It seems to me that in crb's case, both clients are trying to start the
> ad-hoc net. Only one station should generate a BSSID, others should be
> trying to join the net if it exists. Joiners should use their own MAC
> addresses.
>
> I'm not completely clear on the details, but in an IBSS any station can
> generate a beacon, and in fact multiple stations can issue a beacon
> concurrently. A client trying to join passively scans - i.e., first
listens
> for one or more beacons from *some* station, with the desired SSID - or
else
> actively scans (sends a probe with the desired SSID and waits for a
reponse
> from any station). If a beacon or a probe response is received from any
> station in the IBSS - doesn't matter which - the joiner now knows the
BSSID.
> Since any station can beacon or respond to probes, the BSSID should not be
> associated with any particular one. Hence the randomized
> locally-admininstered MAC.

Thanks for the explanation, I now understand (somewhat better) why it is
randomized.
It is kind of confusing though, I guess I need to be an ad hoc client to
totally understand.


>
> I don't know if there is a config issue or not. But it does sound like the
> second station is not trying to join, it's trying to start a net. Try
> bringing one station up first, then the other. Maybe if they both start at
> the same time, they both probe and get no response, so decide to create
the
> net. Or maybe one has to somehow be configured to only be a joiner. How
this
> is done is an implementation detail not addressed in the standard.

This is worth a try. I think crb hs given up and says they just dont workin
ad hoc.....
but we shall see.
>
> >
> > Reading 11.1.3 even makes it more confusing, but it says it generates
> > th lasr 46 bits randomly
> > an the remaing bits are as in 802 1990.
> >
> > So, I dont understand this, maybe you can explain it to me so I dont
> > go telling other people
> > foolish stuff like this.
> >
> >>
> >> The last message:
> >> (E-Mail Removed)
> >> seems to show that he's done all the right tests, tried all
> >> permutations of configurations, disabled the firewall, tried other
> >> computahs, and tested the WET11's with an access point. I can't
> > think
> >> of anything more to try with the two WET11's.
> >>
> >> Well, maybe not. See:
> >> http://www.oreillynet.com/pub/a/wire.../11/wet11.html
> >> in the section starting with "wet 11 useless". Are there any extra
> >> devices (hub or switch) between the WET11 and the computah?
> >>
> >> My best suggestion is to introduce a 3rd (or 4th) Ad-Hoc radio into
> >> the puzzle and test it with either or both WET11. Preferably, it
> >> should NOT be a WET11 to take possible firmware issues out of the
> >> picture. It should also be on an unrelated computah to avoid any
> >> possible computer related configuration issues. Try various
> >> combinations of computahs and wireless bridges. Maybe a pattern or
> >> culprit will be evident. Anyway, this is your thread. You deal
> > with
> >> it.
> >
> > Thanks, I was going to give it to your for Christmas.
> >
> >
> >
> >>
> >>
> >> --
> >> # Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
> >> # 831.336.2558 voice http://www.LearnByDestroying.com
> >> # (E-Mail Removed)
> >> # (E-Mail Removed) AE6KS
> >
>
>

Airhead wrote:

> "gary" <(E-Mail Removed)> wrote in message
> news:eZ7wd.40236$(E-Mail Removed). com...
>
>>"Airhead" <(E-Mail Removed)> wrote in message
>>news:41c01f63$0$800$(E-Mail Removed) m...
>>
>>>>Incidentally, I don't think that Ad-Hoc uses "random" MAC addresses
>>>
>>>as
>>>
>>>>you claim. It uses either the MAC address of the WET11 or the
>>>
>>>cloned
>>>
>>>>address of the connected ethernet card if so configured.
>>>
>>>Well, I didnt quite understand it either, maybe you can clairfiy it.
>>>I got it from 7.1.3.3.3 of the 802.11 1999 standards.
>>>
>>>BSSID field
>>>"The value of this field in an IBSS is a locally administered IEEE MAC
>>>address formed from
>>>a 46 bit random number generated according to the procedure in 11.1.3.
>>>This mechanism
>>>is used to provide a high propability of selecting a unique BSSID."
>>
>>You read correctly. The MAC addresses crb listed are locally administered,
>>as required by this clause (the giveaway is that the first byte is 0x02).
>
> In
>
>>an infrastructure network, the MAC of the AP is the BSSID - but the AP
>
> "is"
>
>>the network, in the sense that it is not a client and it is the gate to
>
> the
>
>>distribution system. In an ad-hoc network, no client "is the network in
>
> this
>
>>way, and a BSSID is invented to distinguish the "net" from the
>
> participating
>
>>clients.
>>
>>It seems to me that in crb's case, both clients are trying to start the
>>ad-hoc net. Only one station should generate a BSSID, others should be
>>trying to join the net if it exists. Joiners should use their own MAC
>>addresses.
>>
>>I'm not completely clear on the details, but in an IBSS any station can
>>generate a beacon, and in fact multiple stations can issue a beacon
>>concurrently. A client trying to join passively scans - i.e., first
>
> listens
>
>>for one or more beacons from *some* station, with the desired SSID - or
>
> else
>
>>actively scans (sends a probe with the desired SSID and waits for a
>
> reponse
>
>>from any station). If a beacon or a probe response is received from any
>>station in the IBSS - doesn't matter which - the joiner now knows the
>
> BSSID.
>
>>Since any station can beacon or respond to probes, the BSSID should not be
>>associated with any particular one. Hence the randomized
>>locally-admininstered MAC.
>
>
> Thanks for the explanation, I now understand (somewhat better) why it is
> randomized.
> It is kind of confusing though, I guess I need to be an ad hoc client to
> totally understand.
>
>
>
>>I don't know if there is a config issue or not. But it does sound like the
>>second station is not trying to join, it's trying to start a net. Try
>>bringing one station up first, then the other. Maybe if they both start at
>>the same time, they both probe and get no response, so decide to create
>
> the
>
>>net. Or maybe one has to somehow be configured to only be a joiner. How
>
> this
>
>>is done is an implementation detail not addressed in the standard.
>
>
> This is worth a try. I think crb hs given up and says they just dont workin
> ad hoc.....
> but we shall see.
>
>>>Reading 11.1.3 even makes it more confusing, but it says it generates
>>>th lasr 46 bits randomly
>>>an the remaing bits are as in 802 1990.
>>>
>>>So, I dont understand this, maybe you can explain it to me so I dont
>>>go telling other people
>>>foolish stuff like this.
>>>
>>>
>>>>The last message:
>>>> (E-Mail Removed)
>>>>seems to show that he's done all the right tests, tried all
>>>>permutations of configurations, disabled the firewall, tried other
>>>>computahs, and tested the WET11's with an access point. I can't
>>>
>>>think
>>>
>>>>of anything more to try with the two WET11's.
>>>>
>>>>Well, maybe not. See:
>>>> http://www.oreillynet.com/pub/a/wire.../11/wet11.html
>>>>in the section starting with "wet 11 useless". Are there any extra
>>>>devices (hub or switch) between the WET11 and the computah?
>>>>
>>>>My best suggestion is to introduce a 3rd (or 4th) Ad-Hoc radio into
>>>>the puzzle and test it with either or both WET11. Preferably, it
>>>>should NOT be a WET11 to take possible firmware issues out of the
>>>>picture. It should also be on an unrelated computah to avoid any
>>>>possible computer related configuration issues. Try various
>>>>combinations of computahs and wireless bridges. Maybe a pattern or
>>>>culprit will be evident. Anyway, this is your thread. You deal
>>>
>>>with
>>>
>>>>it.
>>>
>>>Thanks, I was going to give it to your for Christmas.
>>>
>>>
>>>
>>>
>>>>
>>>>--
>>>># Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
>>>># 831.336.2558 voice http://www.LearnByDestroying.com
>>>># (E-Mail Removed)
>>>># (E-Mail Removed) AE6KS
>>>
>>
>
>
Found a partial solution. See original post.