Particularly agree with this point:

>getting traction from people in resolving problems is
>sometimes hard, especially when people invariably have a
>foregone conclusion as to a root cause in their minds

cheers
lb

Each ap MUST broadcast a beacon as the beacon does more than advertise an SSID. The Service Set IDentifier tells clients stuff like: a) the ap exists , b) supported data rates, and c) lots of other capability information. Only one guest SSID can be advertised per beacon so the more public SSIDs, then the more beacons that must be sent.

The model for the event (as per the recommendations above) is that there will be one public SSID only and that will be advertised in the beacon from each ap. That is the minimum we can get away with while still having wifi work.

The issue above you mention sounds like a classic case of small DHCP scope or lease times too long. We had many thousands of active leases at TechEd last year and it is certainly something that is on my mind from a capacity standpoint.

In regards to supporting 3000+ clients at once – that is going to be problematic as the design goal for the GCCEC WLAN was only 1000 concurrent users. I’ll cover that off in another post in the coming week or so.

So what if you turned off the SSID broadcasting all together? This seems like a pretty big design floor, glad your sorting them out David.

I was at a US event last year where the DHCP server just stopped handing out IP addresses so only the first few hundred people got access. Will this network handle 3000+ devices?