|
Posted by Russ Gimple on May 12, 2005, 9:39 pm
If you were Registered and logged in, you could reply and use other advanced thread options
Hi,
I originally posted this to alt.internet.wireless but was advised to repost
it here because some of you guys here have experience with similar
scenarios. here goes:
We plan to introduce wireless LAN in a couple of student's dorm areas for
web based classroom management software (interaction teachers - students,
knowledge bases etc..) Filesharing and other bandwidth consuming ports will
be blocked.
Which equipment do we need to handle *many* clients, say 200 simultaneous
connections?
Would it be better to think smaller 'cells'?
What about many WRT54GS installed in different corners of the area...?
Thanks for tips and hints for this scenario
Russ
|
|
Posted by Walter Roberson on May 12, 2005, 9:22 pm
If you were Registered and logged in, you could reply and use other advanced thread options
:I originally posted this to alt.internet.wireless but was advised to repost
:it here because some of you guys here have experience with similar
:scenarios.
I'm a bit surprised -- usually Jeff would have a good answer in a
question such as this.
:We plan to introduce wireless LAN in a couple of student's dorm areas for
:web based classroom management software (interaction teachers - students,
:knowledge bases etc..) Filesharing and other bandwidth consuming ports will
:be blocked.
:Which equipment do we need to handle *many* clients, say 200 simultaneous
:connections?
In the past, Jeff (I think it was) has posted information on the number
he has managed to connect to one AP. The WRT54GS is not even in the
running, as best I recall. Whipping my memory cells, I -seem- to
recall him finding that Buffalo was the lowest-end vendor that made
an AP that could handle 50, and that to go much beyond that you needed
to go up the food chain a fair bit.
:Would it be better to think smaller 'cells'?
Yes!
In dorm and classroom areas, there are a *lot* of obstructions. Wiring,
walls, metal rods in the concrete, water pipes -- and *books* are
pretty hard on wireless signal.
In an ampitheatre-style lecture hall, you would need several APs just
to cover the one room.
The alternative longer-distance more-penetrating technology is
known as WiMax -- but it's pretty expensive, -partly- because the
production volume isn't up there [but there are other reasons too.]
If you want to stick with WiFi, 802.11a (54 Mb/s, channels do
not overlap, more common in Europe), 802.11b (11 Mb/s, most common,
the 11 channels overlap leaving you with 3 or 4 effective channels),
or 802.11g (54 Mb/s, 3 channels that do not overlap each other but
overlap 802.11b heavily), then for that scale of a project, you
*really* need a "managed" wireless system.
I'm sure there are a number of worthwhile managed products out there,
but the only one I know anything about is Cisco's 11x0/12x0 series AP's
when integrated with their WLSE. With Cisco wireless cards, or
with select Linksys wireless cards, the cards themselves send signal
strength and quality feedback information to the WLSE, and the WLSE
can dynamically adjust signal strength on the APs in order to provide
the needed coverage whilst trying to minimize cross-channel interference.
The WLSE has built-in site-survey capability. It's interesting
technology -- but it's not SOHO pricing, that's for sure!
:What about many WRT54GS installed in different corners of the area...?
Unless you are planning to replace the firmware on the WRT, then
I would avise great caution before investing heavily in that
solution. Read the reviews of the WRT54GS; read the user ratings.
It is a device that -sells- well, but the user ratings top out
as "fair" with a number of people saying they would never buy
another one. No one particular problem that might be worked around;
I gather that it can behave quite differently in different situations.
When I was trying to decide what to buy a couple of months ago,
*none* of the consumer 54G devices I found had well-satisfied
customers... except for the customers who replaced the firmware.
It was quite discouraging.
In a situation such as yours, I think it would be better for
you to consider dual-radio APs, possibly with WDS ("Wireless
Distribution System"), and with that many users around and
the nature of the users (and the ability of strangers to wander up...)
give serious thought to going 802.1x authentication. WEP should not
even be -considered- in your case (unless as a layer overtop
a different encryption layer such as IPSec.)
A site that tends to have a fair bit of useful WiFi information is
tomsnetworking.com . (It isn't a WiFi oriented site, but they do
some good reviews and tutorials on WiFi.)
--
Beware of bugs in the above code; I have only proved it correct,
not tried it. -- Donald Knuth
|
|
Posted by Keme on May 13, 2005, 2:41 am
If you were Registered and logged in, you could reply and use other advanced thread options
> Hi,
>
> I originally posted this to alt.internet.wireless but was advised to repost
> it here because some of you guys here have experience with similar
> scenarios. here goes:
>
> We plan to introduce wireless LAN in a couple of student's dorm areas for
> web based classroom management software (interaction teachers - students,
> knowledge bases etc..) Filesharing and other bandwidth consuming ports will
> be blocked.
>
> Which equipment do we need to handle *many* clients, say 200 simultaneous
> connections?
>
> Would it be better to think smaller 'cells'?
>
> What about many WRT54GS installed in different corners of the area...?
>
> Thanks for tips and hints for this scenario
>
> Russ
>
>
>
Rather extensive but not comprehensive, based on my memory, which is not
perfect, and my experience, which is for a slightly different scenario.
Here you go:
For equipment, think "administration" and "robustness". The answer I
come up with is Cisco. They handle the DoS attacks we have had better
than our other bases (one rogue user is all it takes, and you're in
trouble), and the options for filtering, VLAN and authentication on
those are more than sufficient. A bit pricey, but you will probably find
it worth the expense, at least if you need more than 3 base stations.
For placement, experiment with different setups. A pc with proper
software (netstumbler or Cain&Abel) can be used for analyzing coverage,
or "cell size". Building materials and construction/architecture can
play a major role.
- Try "even distribution" with power turned way down on all the bases,
versus "clustered distribution", where you'd probably use medium power
output. With 802.11b/g, make sure the bases in each cluster don't
overlap channels. (Spread spectrum with 5 channels overlap, so failsafe
setup must use channels 1,6 and 11).
- Going out to the corners of the house is generally not a good idea.
That way you move 75% of the coverage outside the building. If you are
thinking of internal "corners", you are more on the right track. Some
walls (particularly with steel reinforcing) form radio barriers.
Don't expect to serve more than 60 simultaneous clients from each base
station. (That's if the traffic is mostly client-server, with mainly
peer-to-peer traffic on the infrastructure i'd guess 35-40 simultaneous
users would represent a practical limit.)
Offer basic services (web access, local SMTP, print, files shared
readonly), nothing that requires heavy administration (like distributing
applications or providing traditional file services). The planned "web
classroom service" should work fine (we use something like that).
Network authentication should be lightweight, such as RADIUS, if used at
all. (We have an open network, with authentication on the external line
and on the web "classroom" service only. Local info and print services
are more or less freely available). Logging into domains such as MS
network (Active Directory) or Novell (Netware tree/bindery) seem to load
down the connections with housekeeping. Works fine when you're testing
it, but full scale use shuts the base stations down.
Keep the WLAN on a separate network segment, with no or limited traffic
allowed to pass into the production/teaching network. Use a different IP
subnet for the WLAN segment.
If the students use their own PCs, demand that they have proper security
(at least updated antivirus), and that they don't use network
administration or server/sharing software when they are within the WLAN
cells. (You definitely don't want several DHCP servers on the network,
and just a few KaZaa clients can saturate the network, so you don't want
that either.) Ban the use of all network administration and server
tools/daemons, such as
- DHCP server (often enabled when you share your internet connection)
- Steam (games service)
- P2P file sharing, such as KaZaa, LimeWire, Napster
- Web, chat, ftp or other server software
- Creation of "adhoc" or "peer to peer" networks. (That jams the radio
channels. The students should use the existing infrastructure to
transfer files over network shares.)
- Automatic search for shared resources (default *on* in Windows!).
Switch it off! (Consider 200 PCs with 2 shared resources each, That's
400 shared resources, with 199 possible clients for each. Autoconnect
will give nearly 80000 active connections to be maintained on the
network, probably resulting in a noticeable load both on the network and
on each computer involved.)
As for the "rogue user" I mentioned, you may want to check out
http://new.remote-exploit.org and http://www.oxid.it (and a few others I
don't quite recall) to get some idea of what you should be ready for.
|
| Similar Threads | Posted | | Huge speed dropout with BELL sympatico HSE problem | December 5, 2004, 9:54 pm |
| Huge Arp Cache - Neighbour Table Overflow on IPCOP | July 5, 2005, 11:28 am |
| ZoneAlarm - Port number? | April 23, 2007, 7:06 pm |
| Why is IPS blocking some clients | October 23, 2006, 10:44 am |
| Multiple Cisco Clients | April 12, 2007, 2:37 pm |
| Blocking MSN and other IM clients in corporate firewalls | February 16, 2005, 6:35 am |
| Sonicwall and Windows VPN clients co-existing | October 16, 2005, 9:02 pm |
| Cisco VPN on a PIX525 (no gateway for clients) | June 7, 2006, 8:50 am |
| Connection specific DNS suffix not assigned to VPN clients | April 8, 2006, 1:29 am |
| 3rd Party VPN Clients connecting to Cisco PIX firewall | November 8, 2006, 7:36 am |
|
XML site map