Wireless Access

Do you find KERNEL messages in your Syslog with this error:

 

ieee80211_recv_mgmt 6273 Driver is not able to allocate node

We are using ArubaOS 6.4.2.4 and have seen these messages from models
124 and 125, mostly from model 124. I opened a support call and this
is my interpretation of the answer I got:

 

When the AP receives a management frame, the AP passes the frame to
ieee80211_recv_mgmt() for processing. Data frames received from
associated clients do not get passed off to this function. If the
management frame is a beacon for a node that does not already exist
in the AP’s node table, the function will make a call to something
like ieee80211_alloc_node() to add it to the node table. If the node
cannot be successfully added to the node table then the allocation
routine returns NULL and ieee80211_recv_mgmt() logs the event.

 

Since this error is related to a beacon from a neighbouring or interfering
AP, the error would seem to be benign. However, when the allocation
routine fails, I wonder if one cause could be that no space exists to
add another node, which would seem to imply that there would be no more
room to associate a new client either. It might be worth a closer look
to see if the reporting AP logs the message during a time when it is
saturated with clients.

 

If I have interpreted anything incorrectly, I will rely on Aruba reviewers
to correct me.

We've recently upgraded to 6.4.2.10 and I've been seeing that same error more and more.  It appears to be the AP-125's getting it.  Not sure if it's only those.

 

I can confirm that for us when it's happening on an AP no clients are able to connect.  What makes it tough too is AirWave wasn't reporting anything down, so now I'm checking the aruba logs for 'KERNEL' to keep any eye on this.

Had the same issues with APs. Solved it by rebooting AP only and then we didn't receive it anymore.

When I was on 6.4.2.8 I wasn't getting them.  With 6.4.2.10 I got 6 more today already.  Might have to open something with TAC.  Still only the AP-125s.

Pgemme, that should be fixed in 6.4.2.12. and it was first reported in 6.4.2.9.  You can either upgrade to 6.4.2.12 to sidestep it or downgrade to something before 6.4.2.9

 

 

 

Well, just to be clear, when I opened my case on this issue (1658205) at the beginning of March, we were running 6.4.2.4.

Doug,

That is why I was very specific with pgemme. It is useful on the forum to search for a message when there is a problem, but it can be misleading unless you double check with TAC for specific circimstances and your specific situation. Pgemme should still check with TAC.

Thanks guys, thanks Colin.

 

We were good in 6.4.2.8, not sure we ever ran 6.4.2.4 but the symptom Colin posted looks spot on. Scheduling an upgrade with change control now.  I always prefer going forward.

---

@pgemme wrote:

Thanks guys, thanks Colin.

 

We were good in 6.4.2.8, not sure we ever ran 6.4.2.4 but the symptom Colin posted looks spot on. Scheduling an upgrade with change control now.  I always prefer going forward.

---

pgemme,

 

Please open a case with TAC.  There are a number of things to check to ensure that you end up on the correct version of code and we are addressing what you perceive:

 

1.  If you are running 6.4.2.9 through 6.4.2.10 AND

2.  You see an access point not allowing users to attach and you run this command and get this response:

show ap remote debug anul-sta-entries ap-name <name of ap> 
Module AP STM is busy. Please try later

AND

3.  It is one of these AP models:

AP-124, AP-125, AP-120, AP-121
AP-92, AP-93, AP-93H
AP-104, AP-105
RAP-3WN
AP-134, AP-135
RAP-155, RAP-155P
RAP-108, RAP-109
AP-114, AP-115
AP-103, AP-103H

4.  The message at the beginning of this post *could* be a symptom, but all of these other things must be happening as well.

 

It is best you open a TAC case to ensure this is your issue.  It is also possible you have an unknown issue, or a different issue, but just reading symptoms on a post does not ensure that is your problem...is why you should open a TAC case.

We have done a work-around together with our client to solve this issue.

What we have done is, for all the AP-124 we have created a separate AP Group and on it then we created a separate ARM Profile, where we have disabled Client match. Then we have provisioned all the AP-124 on that group.

For now this has solved our issue.