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.

Reply to
Loading thread data ...

Now what?

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: 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:

formatting link
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.

Reply to
Jeff Liebermann

"> >Jeff, its me airhead.

You have a great sense of humor!


I am practicing on this.


Well, I didnt quite understand it either, maybe you can clairfiy it. I got it from 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.

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

Reply to

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.

Reply to


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.

This is worth a try. I think crb hs given up and says they just dont workin ad hoc..... but we shall see.

Reply to

Found a partial solution. See original post.

Reply to
crb Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.