01-28-2008 06:15 AM - edited 07-03-2021 03:16 PM
We have been doing some testing and we are unable to see if rogues are on wire. I have a rogue plugged in to the network sitting on my desk plugged in to the ethernet cable that typically goes into my laptop and it will not be seen as on-wire.
I do see it as a Rogue, but not an on-wire rogue. I have got it to discover one on-wire rogue by issuing the following command:
config wps rogue-ap rldp initiate/enable <Rogue-ap MAC Address>
When I try to do this with the current Linksys WRT54G test Rogue I get the following error:
RLDP not supported for this rogue-ap entry
The rogue that I finally (After 3 days on wire) got to be discovered as on-wire was a defaulted Linksys WRT54G and my current rogue that I cannot get discovered is locked down pretty well.
It is configured to:
1. Not broadcast SSID
2. WEP Encrypted
3. Not issue DHCP addresses
Does anyone have any ideas as to what I may be doing wrong?
01-28-2008 09:36 AM
Hi Jordan,
Please keep in mind that the on-wire rogue detection mechanism works by the controller attempting to ping itself through the rogue AP.
That means that ANY encryption (even WEP as your rogue AP is using) is going to prevent the (somewhat limited) on-wire detection mechanism from working.
Also, the WLC needs to able to ping itself via a reachable network path where the rogue LWAP is connected. In other words, if the rogue AP is connected to an isolated VLAN which cannot reach the WLC controller, the "on-wire" detection mechanism will also be thwarted.
As an aside, if your testing is also going to evaluate the "rogue client" detection mechanism, keep in mind that there needs to be fairly significant RF traffic between the rogue client and the rogue AP to which it is associated in order for the rogue client to be detected. In part, this has to do with how much time the LWAP has to be checking for security issues while it also performs its primary job of carrying traffic. The rogue traffic needs to be seen during the very brief time slice that it gets between traffic-carrying activities.
I hope this helps,
- John
(Please remember to rate helpful posts)
01-28-2008 09:53 AM
Thanks John.
I was unaware that the encryption would make on-wire detection useless.
01-30-2008 04:14 PM
Yes, this is very interesting and a bit scary!
I too set a Linkys AP to non-broadcast SSID, no encryption, it was not been detected by WCS or the WLC for over a week that is has been up and running. I am using the thibor software:
02-04-2008 07:16 AM
According to the release notes for 4.2, there was/(is?) a known problem in failing to detect on-wire rogues.
I ran into the same problem myself where I setup a test rogue AP (with open security) on the same subnet as the WLC itself. I could PING the WLC from a wireless client connected to the rogue AP, but the controller, while detecting the presence of the rogue AP, was unable to determine that it was on-wire.
As a an aside, the client that I connected to the test rogue AP was *NOT* detected by the WLC as a rogue client. Regarding the failure to detect the rogue client, Cisco TAC said "yes, it's supposed to work that way due to the fact that the LWAP scan fast enough to see small amounts of traffic and do its job as an LWAP at the same time." - Nice! Add to this the fact that the number of rogue clients shown on the summary for the rogue AP will rarely, if ever, match the underlying details records of rogue clients. This should not be surprising since the number of wireless clients on trusted LWAPs shown on the heatmap never matches up with the underlying detail either!
Unfortunately, I have not had time to test if the on-wire rogue AP detection has been fixed in 4.2. The
The bottom line is this: Don't assume that just because the on-wire rogue count is zero that you do not have them.
I do not know if/when this problem is/will be truly fixed.
You may find the following "caveats" regarding rogue AP detecting of interest as well:
CSCsi56611-Client and rogue access point detection might not function properly, and the controller might not respond to SNMP requests.
CSCsi81630-The controller might reboot repeatedly around 5 minutes after startup. This condition usually occurs when the controller, acting as a client station, attempts to associate with a rogue access point.
- John
(Please remember to rate helpful posts)
02-04-2008 07:32 AM
I just upgraded WCS to 4.2.62.11 and Rogue detection is working very well. Immediate discovery of on-wire rogues. I am very pleased with it.
02-06-2008 06:31 PM
I will be upgrading to 4.2.62.11 on the production WCS soon. Will let you know how it goes. The test controller I set up with the latest code 4.2 did detect the rogue the 4.1 version did not. Thanks for fixing that Cisco!
02-15-2008 08:42 AM
Works a lot better. I like the colors for depicting the rogues as known or threat. Sweet improvement. It detected the rogue and shutsthem down quick!
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: