http://www.sans.org/reading_room/whitepapers/auditing/wifi-backtrack_2038
<http://www.sans.org/reading_room/whitepapers/auditing/wifi-backtrack_2038>Here is a whitepaper on using the free backtrack bootable CD to audit and map your wireless network or hire someone to do it. I took the SANS 'Assessing and Securing Wireless Networks' course a few years back and it was well worth the money. Of course, your head may explode by the end of the course :-) The short answer is to use 3 channels and double up on the pair of APs that are furthest apart. YMMV. -Jeff Steward On Tue, Oct 19, 2010 at 10:36 AM, John Hornbuckle < [email protected]> wrote: > The theory behind auto seems good... Listen for a channel that's not noisy, > then use it. But I get what you're saying--there may not be interference on > a particular channel when the WAP boots, but that doesn't mean there won't > be later. > > The trouble is that we have 4 WAPs in close proximity. If I should only use > those 3 channels, what's my best approach? > > > -----Original Message----- > From: Glen Johnson [mailto:[email protected]] > Sent: Tuesday, October 19, 2010 9:23 AM > To: NT System Admin Issues > Subject: RE: Update: Group Policy Problems Over Wireless > > We just had a Cisco site survey done for our wireless and he said "never > set them to auto" for the channel. > > Plot the waps on a map and manually configure the channels to 1 6 or 11 for > minimum overlap. IE, waps on the same channel need to be separated to > prevent interference. We had previously had ours set to auto and following > his advise helped quite a bit. > > His explanation is that, when configured for auto, the wap listens when it > boots and selects the least busy channel. > > That may be good at boot time but could change significantly later on. > > Also, if a wap chooses any channel other than 1, 6 or 11, it can cause > interference with on other channels. > > With these 3 channels selected, you get 3 non-overlapping channels. > > Any other channel will overlap with 2 of the above. > > > > ________________________________ > From: John Hornbuckle [[email protected]] > Sent: Tuesday, October 19, 2010 8:50 AM > To: NT System Admin Issues > Subject: Update: Group Policy Problems Over Wireless > > No firm resolution on this yet, but possibly a bit of progress. > > I kept thinking about the problems we were having in this lab. The > computers are the same computers we had in the lab last year, and last year > we didn't have these problems. So, what changed? Two things: we replaced the > WAPs that serve the lab with newer models, and more WAPs were installed in > that area of the building. > > So I got to thinking that maybe the issue was an incompatibility between > Broadcom NICs and the new WAPs, or an issue caused by too many WAPs being in > the same vicinity. But we have another lab in a different area of the > building that has the exact same WAPs and the exact same computers-but no > problems. So that left the latter possibility-lots of WAPs stepping on one > another's toes-as the prime culprit. > > The WAPs are Cisco/Linksys, and they all default to the same channel. I > changed the ones in the area that was having the problem to "auto," but that > didn't seem to really help. So next I forced the WAPs that serve the lab to > "g" rather than "b/g/n." As moment, everything is working fine. My tech and > I will be watching throughout the week, and if things are still working > after a few days we'll consider the issue resolved. > > > John > > > From: John Hornbuckle [mailto:[email protected]] > Subject: Group Policy Problems Over Wireless > > Short version: > Is there a trick to improving group policy processing when accessing the > network wirelessly? > > > Long version: > We have a lab with machines that have Broadcom wireless NICs in them. Vista > OS, connecting to Server 2008 R2 DC. > > I'm trying to deploy a piece of software to these machines via Group > Policy. I have things setup so that if the machine is a member of a certain > group, the software is deployed. Unfortunately, it only worked correctly on > one of the machines-on all the rest, the software isn't being deployed. > > So I connect to any of the machines that didn't get the software, and run > gpresult. It doesn't show me that those machines are members of the group > that gets the software. But I know they are; I've confirmed in ADUC on the > DC. They're just not picking up group membership. > > Looking at the event log for events that happen around startup, I see > things that make me think group policy processing is trying to happen prior > to the wireless network being initialized. Things like: > > Event ID 5719 (There are currently no logon servers available to service > the logon request.) Event ID 129 (NtpClient was unable to set a domain peer > to use as a time source because of discovery error.) Event ID 1129 (The > processing of Group Policy failed because of lack of network connectivity to > a domain controller.) > > Connectivity to the DC is fine once you get the [Ctrl] + [Alt] + [Del] > window. You can log in (including as someone who has never logged into the > machine before), ping the DC, browse to > \\domain\syvol<file:///\\domain\syvol>, and so on. It's just that at that > point, group policy processing seems to have given up. My machines aren't > figuring out that they've been added to a new group. > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ < > http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected]<mailto: > [email protected]> > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ < > http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected]<mailto: > [email protected]> > with the body: unsubscribe ntsysadmin > > NOTICE: Florida has a broad public records law. Most written communications > to or from this entity are public records that will be disclosed to the > public and the media upon request. E-mail communications may be subject to > public disclosure. > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ < > http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > > > NOTICE: Florida has a broad public records law. Most written communications > to or from this entity are public records that will be disclosed to the > public and the media upon request. E-mail communications may be subject to > public disclosure. > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
