08-23-2006 12:11 PM - edited 07-04-2021 12:55 PM
Can someone recommend a good wireless sniffer for capturing problems after authenticating to the AP? Getting a lot of calls with users login scripts not running or servers not being found. Reboot, and it works just fine. Its like hit and miss, very weird...
08-23-2006 01:05 PM
i use a combination of airmagnet and ethereal, airmagnet to capture the packets and etheral to decode them
08-23-2006 02:47 PM
I use CommView WLAN from TamoSoft (www.tamosoft.com)
It's much less expensive (~US$500.00 for a full license, or $200 for an annual license). They offer a crippled non-timebombed demo version that works with most Atheros-based and Intel-based cards.
AirMagnet and AiroPeek are both thousands of dollars; they have a few more bells & whistles, maybe a little prettier interface ..... but for nuts & bolts capture & analysis, CommView works great.
The issue for any of the wireless "Sniffers" is that the encryption may prevent you from seeing the traffic.
Most can do WEP or WPA-PSK, because you enter the Key value (in the case of WPA-PSK, you need to enter the key, and see the initial exchange with the AP).
If you're using most of the 802.1x / EAP combinations, I don't think any of them can capture, since the key swap and encryption is handled directly between the AP / RADIUS / Host.
Perhaps for diagnostics only, you can set up a WPA-PSK SSID/VLAN so you can watch the authentication and domain login sequences and not suffer too much from the security aspect.
Good Luck
Scott
08-24-2006 05:58 AM
Hmm yes we use some pretty heavy encryption. I didnt even think of not being able to see the trace logs due to encryption. That definately makes things more difficult. I will check out the Commview, havent heard of that one before... thanks!
08-23-2006 04:06 PM
I saw your post, and while I don't have any info to provide you on sniffers, I had similar problems. I found that setting GpNetworkStartTimeoutPolicyValue to be long enough for association with the AP and DHCP to go through.
See http://support.microsoft.com/default.aspx?scid=kb;en-us;840669
08-24-2006 06:00 AM
Well they do get DHCP, its just like finding normal servers either onsite or across the WAN when they log in. They do get logged into the network, just have no drive mappings due to the client not finding the servers.
Its almost like the network cant relay the broadcast messages fast enough through the ip helper command... its weird...
08-24-2006 08:03 AM
Have you tried defining a WINS server, that will help with Widows shares.
We also had luck with defining the servers entire address, for instance server.domain.local instead of just server. This forced it to be looked up with DNS instead of netbios.
08-24-2006 08:34 AM
Hmm well we changed out all the login scripts to IP so I guess we will see if that helps, should point to a DNS problem if thats the case, but weird it only affects wireless stuff...
Still would like to get a trace when it happens, but I have no clue how Im going to do that without making a good chunk of my network open to anyone...
08-24-2006 11:22 AM
omnipeek personal is free and good alternative too ethereal but with wireless support under windows
http://www.wildpackets.com/products/omni/omnipeek_personal/overview
08-26-2006 03:52 PM
I use Airopeek exclusively now. I have a fully licensed copy, which isn't cheap even with my Cisco employee discount. I mainly use the full version because I can do captures from LWAPP APs. However, the free omnipeek has a lot of the really good features in Airopeek.
08-26-2006 02:00 PM
I'd be interested in seeing how that works. I don't know that it working necessarily indicates a DNS problem, since your system will use broadcast name resolution first unless you specify a FQDN. Since the wireless network affects broadcast traffic, we found that to be the problem.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide