[CUWiN-Dev] rfc: fixed bssid

[Stephen Ronan]

David Young wrote (July 27):

>We continue to have problems with IBSS splits in networks with Intersil
>Prism nodes.  As a stopgap measure, I am considering fixing CUWiN nodes'
>BSSID to the oh-so-clever 02:63:75:77:69:6e.
>
>This means that we will not reliably interoperate with Intersil Prism
>nodes, or any other nodes that induce IBSS splits: Aironet? Lucent?
>That might not be bad at all.  I think I can restore interoperability
>with a more permanent future fix.
>
>Thoughts?
>
>Dave

Is this issue something that it would be helpful to take up with any
standards setting bodies at this point?
I ran across this interesting 2002 exchange on the subject in which you
participated, David:
http://lists.bawug.org/pipermail/wireless/2002-August/022779.html

and, while it's not a matter that I understand all that well, I wonder
whether the situation has changed much in regard to the possibilities 
for establishment of helpful standards since then.

A quick Google search shows continuing struggles with the
problem meanwhile among other developers, e.g., there was this message 
from a couple of years ago re: dealing with the issue at MIT Roofnet:

https://amsterdam.lcs.mit.edu/pipermail/roofnet/2003-June/000014.html


and somewhat more recently this in a Roofnet paper:
http://pdos.csail.mit.edu/roofnet/design/
"We originally used the Cisco/Aironet 350, which generally worked well.
However, it suffered from ``BSSID partitioning.'' If different regions
of the network started without being able to talk to each other, they
would choose different random 802.11 BSSID identifiers. New nodes that
came up within radio range of multiple partitions seemed to choose
randomly from them, but the partitions would not always ``coalesce''.
The problem could eventually worsen until the network consisted of
multiple, overlapping BSSID partitions; since a node's 802.11 firmware
filters out broadcasts with the wrong BSSID, nodes in the different
partitions would be blind to each other despite having radio-level
connectivity. It turns out this problem was particularly acute when the
network contained both Cisco 350 and Senao cards. The Senao cards, when
used by themselves, do not seem to suffer from BSSID partitioning."

"As of summer 2004 we're moving to Atheros-based 802.11g cards. We use
our own driver derived from Madwifi. Our driver sends and receives raw
802.11 frames, so that we can control most of the functionality to Click."

And I think this is even more recent:
http://pdos.csail.mit.edu/~rtm/roofnet-b.pdf

"Roofnet operates in the Prism 2.5 chipset's non-standard "pseudo-IBSS
mode. This is similar to standard 802.11b IBSS mode, in that nodes
communicate directly without intervening access points. Pseudo-IBSS
omits the BSSID (network ID) mechanism and does not use synchronization
beacons. This solves a problem with standard IBSS mode in which
partitions form with different BSSIDs despite having the same network
ID. These partitions made it impossible to operate Roofnet raliably."

This may be somewhat less directly relevant but also of  some interest:

www.winmee.org/2005/papers/WiNMee_Ramachandran.pdf
"The beacons also serve to synchronize all the agents to the
same BSSID cell as the manager. This is required because
the unpredictable nature of wireless packet reception can
result in the mesh partitioning into different BSSID cells and
consequently becoming disconnected. As a solution to this
problem, an agent initiates the above described channel scan
procedure (if it does not receive a beacon on the network it
has joined) with the goal of discovering the correct BSSID
cell. In our implementation, the time interval after which the
agent initiates the scan is equal to three times the beacon re-
broadcast interval to allow for any beacon losses"

and same with this item:
http://lists.shmoo.com/pipermail/hostap/2004-December/008919.html

    - Steve Ronan