03-27-2015 05:48 AM
Does your Syslog contain KERNEL messages from various APs that look like this:
Mar 26 18:51 ip-addr1 KERNEL(ap-name-A@ip-addr1): OS_CANCEL_TIMER failed!!
Mar 26 19:05 ip-addr2 KERNEL(ap-name-B@ip-addr2): OS_CANCEL_TIMER failed!!
Mar 26 22:15 ip-addr3 KERNEL(ap-name-C@ip-addr3): OS_CANCEL_TIMER failed!!
Mar 26 22:19 ip-addr4 KERNEL(ap-name-D@ip-addr4): OS_CANCEL_TIMER failed!!
Mar 26 22:16 ip-addr5 KERNEL(ap-name-A@ip-addr5): OS_CANCEL_TIMER failed!!
Mar 26 23:51 ip-addr6 KERNEL(ap-name-F@ip-addr6): OS_CANCEL_TIMER failed!!
I am using 18.104.22.168 but you can find references to this error on AirHeads for
previous versions of ArubaOS. The error is reported by several different
models of APs. I opened a support call on this message and here is my
interpretation of the answer I got:
This has been classified as indicating a minor bug caused by a null pointer
address. The AP uses a timer as part of its logic when managing data that
is buffered for delivery to a client. When a client leaves an AP, the AP
cancels the timer that was being used for that client. Part of this
cancellation routine involves freeing up the data buffer. This would
be done by reference to a pointer. If the pointer has already been freed
or otherwise zeroed out, an error ensues. This manifests itself as a
failure in the routine for cancelling the client's timer.
I can't say with certainty but this would seem to be a benign bug and the
only way you might know about it is if you are checking your Syslog on
a daily basis. The memory allocated to the client is being "double-freed",
the NULL pointer reference is trapped (good programming practice) and
an error is reported.
If I have interpreted this incorrectly I will rely on the Aruba reviewers
to correct me.
03-29-2015 08:32 PM
Bug 107225 was fixed in 22.214.171.124 and was thought to also be the cause of these messages frequently appearing in 6.4.2.x, the reasons being along the lines of the blurb you already received from TAC. I have passed it along to R&D that this message is still appearing in 126.96.36.199 to see what they want to do about it.
Can you please re-onfirm that you are running 188.8.131.52 ? Also what is the model of the AP and can you give a basic description of the topology (i.e. tunnel mode campus APs in a university environment - or something like that)
04-01-2015 05:13 AM
Thanks for your reply. Yes, we are running 184.108.40.206 and we have seen this error reported from AP models 105, 124, 125, 135, and 175. And yes, we are a university. Our master controller manages 2000 APs in tunnel mode to four local controllers.