Network Management

Hello, i'm trying to provision an AP IAP325 to a 7005Controller and i'm receiving this alarms on controller an AP log:

Feb 7 07:03:34 KERNEL(84:d4:7e:cf:5f:5c@xxx.xxx.224.116): [ 42.743236] HTC Rx: insufficient length, got:4 expected =8
Feb 7 07:03:34 KERNEL(84:d4:7e:cf:5f:5c@xxx.xxx.224.116): [ 42.743236] HTC Rx: insufficient length, got:4 expected =8
Feb 7 07:03:34 KERNEL(84:d4:7e:cf:5f:5c@xxx.xxx.224.116): [ 45.607185] HTC Rx: insufficient length, got:4 expected =8
Feb 7 07:03:34 KERNEL(84:d4:7e:cf:5f:5c@xxx.xxx.116): [ 45.607185] HTC Rx: insufficient length, got:4 expected =8

Does anybody knows something about this issue?

Thank you

Gabriel

That could be cosmetic.  Is the AP working?

Not, is not working. And the controller shows the AP as disconnected just 30sec after showed UP when the AP has completed the boot process.

Type "show log system 50" to see what is the issue.  Also type "show ap database" to see if there are any flags.

Did you already convert it from an IAP to  Campus AP?

In replying this thread since I got similar issue here. It's an IAP-305 converted to CAP. Show ap database showed it as dirty and AP then changed state to down. It stays down, although its IP address replies to pings. Doesn't accept SSH connection so I'd assume there hasn't been any kind of deconversion back to IAP. Show datapath session doesn't show any traffic from the AP's IP address on controller.

Any ideas? Console is not option here due to 200+ kms in between myself and the AP (not to mention the again-another-special-console-cable console port).

FWIW this is what I find in the logs:

- system log:

Jun 15 08:17:52 :303022:  <WARN> |AP c8:b5:ad:c5:87:b2@10.206.134.190 nanny|  Reboot Reason: AP rebooted Wed Dec 31 16:44:26 PST 1969; SAPD: Unable to contact switch: HELLO-TIMEOUT. Last rebootstrap reason: HELLO-TIMEOUT, 228 sec before: Last Ctrl msg: HELLO len=1246 dest=10.206.134.131 tries=10 seq=0
Jun 15 09:01:43 :311002:  <WARN> |AP c8:b5:ad:c5:87:b2@10.206.134.190 sapd|  Rebooting: SAPD: Unable to contact switch: HELLO-TIMEOUT. Last rebootstrap reason: HELLO-TIMEOUT, 228 sec before: Last Ctrl msg: HELLO len=1246 dest=10.206.134.131 tries=10 seq=0
Jun 15 09:04:12  KERNEL(c8:b5:ad:c5:87:b2@10.206.134.190): [   27.890446] HTC Rx: insufficient length, got:4 expected =8
Jun 15 09:04:12  KERNEL(c8:b5:ad:c5:87:b2@10.206.134.190): [   29.484841] HTC Rx: insufficient length, got:4 expected =8
Jun 15 09:04:13 :303022:  <WARN> |AP c8:b5:ad:c5:87:b2@10.206.134.190 nanny|  Reboot Reason: AP rebooted Wed Dec 31 16:44:26 PST 1969; SAPD: Unable to contact switch: HELLO-TIMEOUT. Last rebootstrap reason: HELLO-TIMEOUT, 228 sec before: Last Ctrl msg: HELLO len=1246 dest=10.206.134.131 tries=10 seq=0
Jun 15 09:48:05 :311002:  <WARN> |AP c8:b5:ad:c5:87:b2@10.206.134.190 sapd|  Rebooting: SAPD: Unable to contact switch: HELLO-TIMEOUT. Last rebootstrap reason: HELLO-TIMEOUT, 228 sec before: Last Ctrl msg: HELLO len=1246 dest=10.206.134.131 tries=10 seq=0
Jun 15 09:50:33  KERNEL(c8:b5:ad:c5:87:b2@10.206.134.190): [   27.904931] HTC Rx: insufficient length, got:4 expected =8
Jun 15 09:50:33  KERNEL(c8:b5:ad:c5:87:b2@10.206.134.190): [   29.498142] HTC Rx: insufficient length, got:4 expected =8
Jun 15 09:50:35 :303022:  <WARN> |AP c8:b5:ad:c5:87:b2@10.206.134.190 nanny|  Reboot Reason: AP rebooted Wed Dec 31 16:44:26 PST 1969; SAPD: Unable to contact switch: HELLO-TIMEOUT. Last rebootstrap reason: HELLO-TIMEOUT, 228 sec before: Last Ctrl msg: HELLO len=1246 dest=10.206.134.131 tries=10 seq=0

- ap-debug log:

Jun 15 10:07:56 :305062:  <3905> <DBUG> |stm|  sapm_ap_add_config_group: AP c8:b5:ad:c5:87:b2: group ids_prof inst "default" lic 1 g_sm 8 g_sv 8 p_sm 29360256 p_sv 0 ni 1 fap 0
Jun 15 10:07:56 :305062:  <3905> <DBUG> |stm|  sapm_ap_add_config_group: AP c8:b5:ad:c5:87:b2: group ap_mesh_radio_prof inst "default" lic 1 g_sm 8 g_sv 8 p_sm 29360256 p_sv 0 ni 1 fap 0
Jun 15 10:07:56 :305062:  <3905> <DBUG> |stm|  sapm_ap_add_config_group: AP c8:b5:ad:c5:87:b2: group am_filter inst "default" lic 0 g_sm 8 g_sv 8 p_sm 29360256 p_sv 0 ni 1 fap 0
Jun 15 10:07:56 :305062:  <3905> <DBUG> |stm|  sapm_ap_add_config_group 3845: AP c8:b5:ad:c5:87:b2 group ap_group param arm_rf_domain_prof type profile sel 0
Jun 15 10:07:56 :305062:  <3905> <DBUG> |stm|  sapm_ap_add_config_group 3872:AP c8:b5:ad:c5:87:b2 Recursing with groups 0x15a8444:ap_group,pgroup 0x7317e8, pgroup->name arm_rf_domain_prof  param->name arm_rf_domain_prof
Jun 15 10:07:56 :305062:  <3905> <DBUG> |stm|  sapm_ap_add_config_group: AP c8:b5:ad:c5:87:b2: group arm_rf_domain_prof inst "default" lic 1 g_sm 8 g_sv 8 p_sm 29360256 p_sv 0 ni 1 fap 0
Jun 15 10:07:56 :305062:  <3905> <DBUG> |stm|  sapm_ap_add_config_group: AP c8:b5:ad:c5:87:b2: group ap_provisioning_prof inst "" lic 1 g_sm 8 g_sv 8 p_sm 29360256 p_sv 0 ni 0 fap 0
Jun 15 10:07:56 :305062:  <3905> <DBUG> |stm|  sapm_ap_add_config_group: AP c8:b5:ad:c5:87:b2: group ap_authorization_prof inst "" lic 1 g_sm 8 g_sv 8 p_sm 29360256 p_sv 0 ni 0 fap 0
Jun 15 10:08:08 :305003:  <3905> <INFO> |stm|  AP c8:b5:ad:c5:87:b2 is down

It seems that the IAP is unable to reach the controller. Is basic connectivity in place between the IAP and controller? What is the AOS version you are running on the controller. You will need a minimum of  ArubaOS 6.5.1.0, 8.1.0.0 on the controller to support an AP-305.

This IAP was succesfully converted to CAP and was able to register to controller. This problem of mine occurred when I was playing with DHCP vs. DNS controller discovery process and rebooting the AP several times (I was testing one customer problem).

Controller in question is running AOS 6.5.4.3. Controller and AP reside within the same LAN segment, it's a flat L2 piece of network.

Now guess what.. the AP is up and running. I didn't touch it, but there it is, registered to controller. Uptime almost four days now (3d 19h), so magic weekend troll must have done her trick. Again. It would be really nice to understand what an earth has happened here.

EDIT: While digging into this and browsing the controller logs I noticed controller uptime which is in sync with the AP uptime. I don't recall if I rebooted the controller when frustrated to all this, but most likely. I'll keep on playing with the setup and see if I can reproduce this one. Just to let you know: in case somebody runs into same kind of issue start by rebooting the controller..

In my case the solution was to disable deep packet inspection on the firewall (disable filtering by application or port)