Greg Troxel <[EMAIL PROTECTED]> wrote:

|(Apologies if this is an old subject; I'm new to the list, but have
|been playing with wlan stuff since 1997.)

I've brought up the BSSID convergence issue from time to time.  It never
provoked the kind of exciting discussion I expected. :)

|In an adhoc network, IBSS mode seems a natural choice,

That's what I thought a few years ago, but I changed my mind.  The convergence
issue was a big reason, but there seem to be other incompatibilities among
vendors in ad-hoc mode.  I've seen cases where two cards would appear to have
formed a network (and their respective utilities would confirm this) yet packets
failed to pass between them.  Of course, if you can constrain your network nodes
to use only one vendor's hardware this may not be an issue.  I didn't want to
give up the ability to use, e.g., the built-in WiFi on a PocketPC, so I couldn't
impose that constraint.

|I wondered: what if I set up two such nodes, far apart enough that
|they can't hear each other's packets, and then bring them together?
|From reading the 802.11 spec, it seems that packets with a different
|BSSID will not be received (at layer 2); this is the normal network
|separation in infrastructure mode.  So, will the nodes not be able to
|interoperate, since they are in their own IBSS?

That would be the expected behavior absent any BSSID convergence algorithm
implemented by the vendor outside of the standard.

|I tried this, with one node having an Lucent/Orinco Gold card, and the
|other (both NetBSD 1.6.1) a PRISM2.5 (IBM T30 builtin).  The BSSID for
|the PRISM2.5 card was formed in the canonical manner (set 0x20 in
|first byte, copy rest of MAC), except the middle 2 bytes were
|changing, and the Lucent BSSID was exactly normal (0x20 set in first
|byte, other 5 the same as MAC).
|
|Despite having been set to "IBSS channel = 3", and showing current
|channel 3 when first configured (several km away), after driving
|closer to the first node (but still out of range - 200m away), it
|showed channel 6.

Perhaps it saw some other party's system on channel 6 and tried to join?

|When I got within range, I found that the
|stationary node (with a Lucent card) had adopted the BSSID of roving
|PRISM, and moved to Channel 6.

Given that it adopted the BSSID it had to adopt the channel, so that in and
of itself is not surprising.

|This is quite odd; it seems like the PRISM card might have been
|scanning even though it should have been 'creating'.

Presumably you are seeing two vendor's attempts at BSSID convergence.  I
think most vendors try to handle at least this degenerate case, i.e., a
single-member IBSS.  The more interesting question is what happens when
you have two or more groups each with multiple members and try to merge.

|I don't recall the standard speaking to the issue of "merging" two
|IBSSs.

As far as I can tell, it doesn't.  This is left as an implementation detail.

|But it seems clear to me that IBSSs with the same SSID should
|join together somehow - at least because that's what I want to have
|happen.

Right, that's what I wanted as well.  Alternately, I would be happy if I
could simply hard-wire the BSSID itself on all the clients.  Nobody seems
to supprot this, though.

|Does anyone know if this behavior is universal with all cards that
|support IBSS mode?  Specifically, how about IBSS mode on the ADMtek
|and Atheros chipsets?
|
|Can anyone point out anyplace in the specifications where this is
|addressed?

I'd be interested as well...

                                Dan Lanciani
                                [EMAIL PROTECTED]
--
general wireless list, a bawug thing <http://www.bawug.org/>
[un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless

Reply via email to