Thread: [Aironet] ad hoc coalescing problems with 4.25.10
Status: Inactive
Brought to you by:
breed
From: Daniel A. <ag...@am...> - 2001-11-14 01:56:12
|
Hi all, I'm involved in some ad hoc networking research, and recently I've encountered some weird behavior that is causing partitioning of our network. First, about our set-up: we have twenty PC's, running OpenBSD 2.9, spread out among two floors of our building. Each is equipped with an Aironet 340 PCI card running in ad hoc mode and with matching SSID's. The firmware is version 4.25.10. Until recently, this set-up was working fine for us, and all the nodes were setting matching BSSIDs and forming a contiguous network. Last week, however, the network partitioned itself seemingly without reason: now there are two sets of nodes, one with a sensible BSSID (00:02:2d:1f:3a:4a), and one with BSSID ff:ff:ff:ff:ff:ff. The two sets of nodes are unable to communicate with each other, despite physical proximity (in one case, one node from each set are in the same room). However, within the nodes of each set, operation is continuing as normal. Has anyone ever seen anything like this? It's possible that this happened as a side effect of some nodes rebooting for the sake of software upgrades: is there any way that multiple nodes coming up simultaneously could result in this weird condition? If so, is the "all ones" address treated specially, preventing the cards from later settling on a single BSSID? Within the last few weeks, we've also had some PCMCIA WaveLAN cards join in the network. I've noticed that they misbehave on occasion, for example sometimes choosing their own BSSID despite being within range of the Aironet hosts. Could their presence have led to this situation? Or, could the unusual situation with the Aironet cards cause the WaveLAN cards' misbehavior? Simply rebooting all the nodes will almost certainly correct this problem, but I'm hesitant to do so until I have a better understanding of why this has occurred. As our network continues to grow, such a solution will grow more and more impractical if this ever happens again. I would appreciate any insight or advice anyone can provide. Thanks in advance. dan |
From: Jim V. <jv...@ci...> - 2001-11-15 16:41:26
|
The all FF's BSID problem is a result of a bug in current firmware responding to probe requests incorrectly. This has been fixed in firmware we are currently testing with, And no - I don't know when it will be released ;-) Jim On Tue, Nov 13, 2001 at 08:56:10PM -0500, Daniel Aguayo wrote: >=20 > Until recently, this set-up was working fine for us, and all the nodes > were setting matching BSSIDs and forming a contiguous network. Last > week, however, the network partitioned itself seemingly without > reason: now there are two sets of nodes, one with a sensible BSSID > (00:02:2d:1f:3a:4a), and one with BSSID ff:ff:ff:ff:ff:ff. The two > sets of nodes are unable to communicate with each other, despite > physical proximity (in one case, one node from each set are in the > same room). However, within the nodes of each set, operation is > continuing as normal. >=20 --=20 | | Jim Veneskey :|: :|: Software Test Engineer :|||: :|||: 320 Springside Drive Suite 350, Akron OH 44333 =2E:|||||||:..:|||||||:. Email: jv...@ci... |
From: David B. <dav...@bo...> - 2001-11-28 06:12:03
|
Is there a way to pin a 350 card to a specified channel in ad-hoc mode ? The cards seem to ignore a configured channel, which might be sensible in most applications, but I have two cards in the same machine and would like to have them transmit on different channels. They're currently both deciding to use channel 6. Thanks. |