how many connection can I have?

Have you ever tried to connect 254 wireless devices to a Linksys router? I think it fall down and go boom much sooner.

Correct me if I'm wrong (no big leap in logic there) but it seems as though you are discussing more theoretical connections, even if you actually were generating connections. I mean, 253 real world users actually attempting to use the net at the same time? No hidden node problems? No extremely high collisions? All this without polling software?

253! There can be 254 hosts in a class C subnet and the router is the first them.

Thomas

I have. It can be simulated by randomizing the clients MAC address (BSSID) which simulates multiple client connections. Most of the older cheapo access points and wireless routers barf at 32 MAC addresses total (including the access point itself). One piece of junk firmware would only do 8 MAC addresses until it was finally fixed just before the product was killed. A few will do about 50 addresses for some unknown reason. If you have a limited range of DHCP assignable IP addresses, most routers will allocate as many IP addresses as available, and then refuse to associate or to issue any more IP's until either reset or DHCP times out. Some current access points, such as the WRT54G and WAP54G will do 253 clients. The WRK54G is a stripped down version of the WRT54G and should have similar specs.

The Proxim, Orinico, Avaya, Wavelan, Agere, Lucent, whatever access points will do 1024 or 2048 depending one whether it's a 1 or 2 card access point. More important, they seem to have a functional "least recently used" algorithm for expiring stale associations and DHCP entries. I couldn't hang or kill any of these I tested. However, I did manage to screw up the DHCP server and where it would not give out any more IP addresses until table entries were available. This seemed to be timer based, were nothing would happen for about 10 minutes(???), and then a huge number of IP addresses were suddenly available. This is not a problem as the probability of having 1024 users simultaneously try to associate is rather limited.

For reference, the 253 comes from: The maximum addresses available is 256 (.0 thru .255). .255 is used as the broadcast address. .0 is the entire network and not useable. ..1 is usually the access point itself. 256 - 3 = 253 Now, if you want some fun, setup the range of DHCP assignable IP addresses to cover the entire .0 thru .255 range and start consuming DHCP assignable IP addresses. For a while, one vendors firmware would merrily pass out .0 .255 and the address of the access point when it ran out of IP addresses. This was fixed but only after various hot spot operators ran into the problem as they really might have over 253 potential users in crowded conventions, ball parks, and such.

I was generating 253 simulated connections (associations) with corresponding DHCP delivered IP addresses. However, there was only traffic from one IP address at a time. That's not a very realistic test for real world conditions. Conventional wisdom and rule of thumb is that the average WISP access point can handle per channel: 100 casual users checking email and light web browsing. 10 business users doing whatever business users do. 1 teenage Napster/Kazaa/Bearshare/Morpheus/whatever user. As you may notice, it's not the number of connections, but what they're doing (i.e. traffic pattern).

I've done traffic load tests in a laboratory environment using about

40 computahs. It was quite a mess and I spent much of my time dealing with issues that had nothing to do with wireless loading. The plan was to optimize some timing, flow control, and retrans algorithms. I spent the first hour dealing with two of the machines that apparently had a worm and were generating lots of junk traffic. The next hour was spent changing the SSID to something that wasn't duplicated elsewhere in the lab. Another 30 minutes or so was spend disarming the screen blankers and power save features that kept shutting down the laptops and PC's at inconvenient times. This type on nonsense went on all afternoon. I finally got about 2 hours of testing done. Not enough to do a decent job, but enough to check for obvious problems. No real problems. Bandwidth distributed itself equally between active computahs as expected.

I also got the chance to test the effectiveness of CTS/RTS flow control. Didn't make any difference in aggregate thruput since there were no hidden nodes in the lab. Everyone could hear everyone else so there were no collisions. So much for that test.

I once did some modeling to see at what point polling (i.e. Karlnet TurboCell, 802.11e (draft spec), 802.11 PCF (point coordination function, etc) schemes were beneficial. My seat of the pants guess(tm) is that about when about 20% of the active clients qualify as hidden nodes, polling is highly beneficial. It doesn't take many collisions to screw things up. Probably somewhat beneficial at smaller number of hidden nodes. In general, outdoor networks should use polling (or flow control) while indoor networks can get away with CSMA/CA. For point to multipoint, where the clients all have directional antennas, flow control is manditory and polling is highly benificial, since none of the clients can hear any of the other clients.

The router can NAT 253 addresses, so theoretically ~249 or so.

Practically tho, most consumer wireless units fall over WAY before that and remember each one gets 1/Nth of the total wireless bandwidth.