Potential Honeypot AP - WLC-4402-25-K9 - 5.0.148.0

Unanswered Question
Mar 17th, 2008
User Badges:

In the Trap logs on a WLC I see messages like this one:


Potential Honeypot AP: <honeypot-MAC> on Base Radio MAC: <reporting-MAC> Interface no:0(802.11b/g) with SSID: <ssid>


Both the honeypot-MAC and the reporting-MAC are MAC's belonging to APs managed by the WLC.

This particular WLC is a WLC-4402-25-K9 running 5.0.148.0.


Is my WLC misconfigured or is this a (known) bug in 5.0.148.0?


Trond.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
fopravil Wed, 04/23/2008 - 12:26
User Badges:

Hi,

I have found the same messages in the trap log after the controller upgrade to 5.0.148.0, the only difference I found is that the honeypot-MAC is not a MAC of AP's managed by the WLC.

Wireless clients works as before upgrade.

mlrtime99 Wed, 06/18/2008 - 10:34
User Badges:

Same here after our upgrade to 5.0.148.0. It is identifying it's own radios by base radio MAC's as honeypot AP's. I first thought it was doing this because of our Public wlan which has it's SSID broadcast and no security. But it's also identifying AP's running hidden SSID's and wep security.


I can't speak for performance impact as we don't have any clients right now but it has definitely rendered our email alerts useless unless we want a critical alarm every second. Unless someone responds we'll have to look at rolling back to v.4 C'mon Cisco do a little testing before pushing this stuff out.

mlrtime99 Fri, 06/20/2008 - 12:03
User Badges:

These alarms cease if broadcast SSID is disabled on the wlan. This is not a workable solution for us since the wlan is a public/free network. Anyone come up with anything else? I couldn't find a signature definition to delete either.

johnmdolan Wed, 07/23/2008 - 12:39
User Badges:

I had many weird issues with 5. and ended up going back to 4.2. I think I will just wait a bit to go to 5

kfccolonel Fri, 07/25/2008 - 17:56
User Badges:

Its a known bug. If you want to get these warnings out of the logs, the best work around is to shut off 'rogue detection' in the SNMP settings....otherwise live with it until you move to 5.1

Actions

This Discussion

 

 

Trending Topics - Security & Network