HOWEVER, it really boils down to a number of factors. For example:
What kind of traffic? (Voice? General Surfing? Database access? Telnet/SSH?) More traffic means fewer supported (happy) users.
How much interference is in that area? (More interference means fewer users - the AP still has to take time to recognize invalid users, and to re-transmit traffic corrupted by interference)
Are you going to try to run DHCP, RADIUS or WDS services from a/the/some APs? (there's only so much processor and RAM to go around - more proceses means fewer supported (Happy) users).
Are you going to support a wireless network of 802.111g only, 802.11b/g, or 802.11a ? (*any* 802.11b clients will downshift the available bandwidth .... if you have *any* 802.11b clients in the area - valid or rogue - it will diminish your available bandwidth, unless you specifically exclude them - fewer (happy) users.
There are some other minor factors, but I think you'll find these to be the major show-stoppers.
You may also want to pay close attention to the antennas & depolyment of the antennas to provide adequate diversity, minimize interference, and optimize the system for the area-of-use.
Bottom line: you need a *really* solid site survey, and a *really* solid analysis of the traffic flows to have any decent chance of success.
a single access point can handle about 2000 assoications to it, but 15 to 25 active clients at once. This is a limitation of 802.11. If you have 100 clients that are wireless, I would consider at least 4 ap's if they are all active.
As more and more users associate to an AP and use demanding applications, do the users just get very slow response because more folks are sharing the same bandwidth? Or would other symptoms occur as well, like more frequent disconnects...?
I believe either could happen (gets slow, users start to drop).
This is not shared bandwidth the same way that, say, Ethernet is through a hub; the difference is how contention is handled.
In a hub, if two (or more) stations happen to transmit at the same time, they'll fall back, wait, try again. There's a formula, and some randomness is introduced so the next attempt by each "probably" will happen at different times (uses collision detection)
With wireless, the AP coordinates (by poll) all of the associated clients; the more clients associated, the longer the poll cycle. If there's some "dead air" time, a client can request time to transmit and has to wait for permission to proceed. (uses collision avoidance)
Thre are some other modifiers to the poll cycle and the transmission/response timing; generally speaking, no associated client can "speak out of turn" .... even to save the association. It'll time out, then re-associate.
If the system is still overloaded, the clients wait their turn, possibly, randomly time-out .... and occasionally drop.
While the APs usually can support a very large number of associations, in practice, the number of active clients any given AP can handle will be determined by how much of what kind of traffic is present, how much interference is in the environment, and some other factors (like processing power of the AP, memory, operating modes (802.11 b only, 802.11g only, mixed B/G modes, etc).
The Planet 3 book for studying CWAP (published by Osborne) has a pretty good description of the specific details ... check it out, it would be an excellent addition to any wireless library, even if you aren't studying for the Certified Wireless Analysis Professional certification.
Transferring Crash file from standby: Login to the Active WLC in HA.
From CLI: (Cisco Controller) >transfer upload datatype crash (Cisco
Controller) >transfer upload filename (Cisco
Controller) >transfer upload mode tftp (Cisco Controller) >transfer
This is the start of a display filter cross reference between Wireshark
and OmniPeek. The 1st installment is a table of advanced filters. More
filters will be added as time allows. It is a living doc, so check back
for changes every so often Please feel f...