MSM760 Log Help

[PaulC1]

We have had various issues with our wifi which is an msm760 with approximately 150 AP's, (HP560, MSM460 primarily)

We an SSID with Radius enabled but sometimes users just cannot connect or if they are connected they sometimes get kicked off and then struggle to reconnect.  The signal stregth is good in all areas.

I looked at the logs from the MSM760 and there are an awful lot of entries (1000's) as below at a rate of 10+ a second.

The ip/id/port are different for each entry.

Discarding RADIUS Accounting Request (id='36') from RADIUS Client (ip-address='169.254.0.60',port='32880') because of missing username. (Check your RADIUS Secret configuration.)

Does anybody know what may be causing the issue.

Thanks in advance if anybody can offer any assistance.

[RamKrish]

Whole log might help to see what other relevant logs along with this accounting messages.

Who is the Radius server?  (Microsoft NPS ? or other?)

Do you really need to use Accounting? is Radius accounting configured properly?

May be a wired trace on your radius server might help to see what kind of radius replies going to the controller.

Do you have a screen snap of your VSC settings?

[hpehh]

Hello PaulC1,

do you found a solution for this problem? I get the same type of error every 5 sec. on the MSM760. It happened after an update on firmware 6.6.2.0-22792. We don't use RADIUS Accounting but authenticate through RADIUS against OpenLDAP.

Thank you! 

[Transport]

The error suggest the wrong key used between wireless controller and radius-server.
When the the controller can't authenticate against the radius, it can't see if the username excists or not. Hence the error about the username.

Please check is the keys are correct on your controller AND radius server


See screenshots attached.

[richlo]

I have a customer with the same error under 6.6.2:

iprulesmgr: Discarding RADIUS Accounting Request (id='99') from RADIUS Client (ip-address='169.254.0.59',port='34006') because of missing username. (Check your RADIUS Secret configuration.)

Was setting the correct key between the radius server and the controller the answer?

Thanks,

RO

[OX-ITS]

We're having the same problem, also 6.6.2. Setting the "correct" key isn't the awnser in our case.

To make it more fun, the Radius accounting to our Windows NPS/Radius server is working perfectly, even though we get these messages. We don't have any other Radius connections to/from the MSM controller.

When rebooting the messages dissapear for a few minutes, but sadly return if they never have left.

We're lacking the know-how to find what (or who) is causing these messages, looking at one of the many logs doesn't reveal us much.

[Teufel Martin]

We are haveing the same in out Logfiles:

iprulesmgr: Discarding RADIUS Accounting Request (id='218') from RADIUS Client (ip-address='169.254.0.50',port='36226') because of missing username. (Check your RADIUS Secret configuration.)

Has anyone a solution or some info on that issue?

KindRegards

Martin

[CraigS1971]

Hi Paul and Martin,

Run your radius server in debug mode and write the output to a file.
Check that the username and password are reaching the radius server correctly.

The command may look like this depending on the OS and radius server:
/usr/sbin/radiusd -d /usr/local/pf/raddb/ -X -xx | tee radius_debug.log

Search for something like this: (rdomingo + P@ssw0rd)

Thu Feb 25 08:19:05 2016 : Info: performing user authorization for rdomingo
Thu Feb 25 08:19:05 2016 : Info:  <------>expand: (uid=%{User-Name}) -> (uid=rdomingo)
Thu Feb 25 08:19:05 2016 : Info:  <------>expand: o=csir -> o=csir
Thu Feb 25 08:19:05 2016 : Debug:   ldap_get_conn: Checking Id: 0
Thu Feb 25 08:19:05 2016 : Debug:   ldap_get_conn: Got Id: 0
Thu Feb 25 08:19:05 2016 : Debug:   performing search in o=csir, with filter (uid=rdomingo)
Thu Feb 25 08:19:05 2016 : Info: Added the eDirectory password P@ssw0rd in check items as Cleartext-Password

You can also search for messages regarding incorrect authentication from clients ie MSM controller ip address.

Regards,

Craig.

[Teufel Martin]

Hi Craig!

Thanks for your Reply.

I looked into the radiusserver Logs, but didn't help me. I didn't find there any specifc Radius Audit Requests.

One interesting thing is the originating IP adress of the failed Radius-Requests. These are all 169.254.x.x adresses. Why does the MSM have/use them?? We are running a Teaming Setup with two MSMs and the faild Radiusrequests are only reported on one of the systems. The MSMs are on the Same Subnet.

Kind Regards

Martin

[CraigS1971]

Hi Martin,

The APIPA addresses (169.254.x) are normally a DHCP problem.

Do you use DHCP for your APs or controllers?

Check that your controllers have valid static ip address and also check the AP ip addresses.

Regards,

Craig.

[Teufel Martin]

hi!

Both controller  have static IPs on both interfaces.

The APs get IP from an DHCP Server (not the MSM). All APs have correct and working IPs.

Martin

[CraigStrydom71]

Is your certificate still valid? Check expiry date.

What happens if you reboot the controller with the errors? Do the errors start again?

Someone else had a similar problem: http://community.hpe.com/t5/MSM-Series/Possible-DoS-attack/td-p/5905593

[sjordet]

Hi!

Have the same issue after upgrading to 6.6.2.0 - and it's still there with 6.6.3.0.

I made a case with support, and as expected they weren't very helpful. They requested a packet trace of the radius traffic. I haven't had the time to do that yet, but I doubt there is any traffic there. We don't use Radius accounting, and we have no problems with our radius authentication at all. Everything works as expected, except the log messages.

I also got a question about expired certificates, but as far as I can see, I have no certificates that expire untill 2017 at least.

I seem to remember that the 169.254.x adresses are adresses assigned to the AP's on the inside of the encrypted tunnel. We also have a team, and about 300 AP's.

Since it doesn't seem to affect anything here, I haven't bothered to pursue this, but it's still a bit annoying to have my logs flooded. And we are at least a few users experiencing the same, so hopefully HP will figure it out before we are forced to move to Aruba ;)

[Arimo]

Hi all

This issue is currently in the lab under investigation. If you're experiencing this, please contact support.

[JKetterer]

We are also seeing this. Has there been any resolution? 

Sample error from our syslog:

Aug 26 13:36:42 10.241.0.6 MSM760-Local- iprulesmgr: SG1113N03B Discarding RADIUS Accounting Request (id='91') from RADIUS Client (ip-address='169.254.8.119',port='33810') because of missing username. (Check your RADIUS Secret configuration.)

Jim Ketterer

[sjordet]

Yeah, it's been fixed in 6.6.4.0 :)