Wireless Access

We are having problems on converting IAP-103 running firmware 6.4.2.6-4.1.1.11 to Campus. The controller is a 7205 running 6.5.4.3.

Using the console I can see a FTP timeout downloading the firmware from the controller. Running ping from the access point does not show any problem.

After upgrading IAP firmware to 6.5.1.0 and trying to convert the IAP again, we have the same problem. It's impossible to convert the AP, although there is apparently proper level 3 connectivity between them.

'show log convert' shows three attempts to download mips32.ari resulting on "Connection time out". No ACL on controller-IP.

On the controller side, the FTP traffic between AP and controller is seen:

Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Packets Bytes Flags
--------------- --------------- ---- ----- ----- -------- ---- --- --- ----------- ---- --------- --------- ---------------
10.109.199.197 10.82.15.154 6 21 63879 0/0 0 8 0 0/0/1 4 1 44 I
10.82.15.154 10.109.199.197 6 63879 21 1/15784 0 8 0 0/0/1 4 1 60 YCUI

Any idea?

The "Y" flag means no SYN, so it seems like there is still a connectivity issue between the IAP and the controller

You are right. There was a connectivity problem between IAP and the controller in our level-3 IP service provider.

To simplify, I connected the IAP to the controller's IP vlan. After that, the IAP downloaded the firmware and rebooted. Nevertheless, on rebooting the converted AP does not register on the controller (the IAP  is included in the whitelist - certified-factory-cert - factory-cert type ). The datapath session table shows an initial connection from the AP to 514 port (syslog), then to PAPI port (8211) but the AP does not appear in the 'ap database'. There is an 'Y' flag in only one direction but AP and controller share the same vlan and switch. I can't understand what is happening.

Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Packets Bytes Flags
--------------- --------------- ---- ----- ----- -------- ---- --- --- ----------- ---- --------- --------- ---------------
10.109.199.197 10.109.199.203 17 514 49152 0/0 0 0 1 0/0/1 12 0 0 FY
10.109.199.203 10.109.199.197 17 49152 514 1/15785 0 0 1 0/0/1 12 0 0 FC

Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Packets Bytes Flags
--------------- --------------- ---- ----- ----- -------- ---- --- --- ----------- ---- --------- --------- ---------------
10.109.199.203 10.109.199.197 17 8211 8211 0/0 0 0 1 0/0/1 1a 0 0 FCI
10.109.199.203 10.109.199.197 17 8211 8222 0/0 0 0 1 0/0/1 1a 0 0 FYCI
10.109.199.197 10.109.199.203 17 8222 8211 0/0 0 0 1 0/0/1 1a 1 149 FI
10.109.199.197 10.109.199.203 17 8211 8211 0/0 0 0 1 0/0/1 1a 0 0 FYI

The "Y" flag is only a problem for TCP traffic.  For udp traffic like papi (udp 8211) and syslog (udp 514) it is expected.  UDP traffic does not have a "syn", so that is okay.

I would type "show log security 50" or "show log system 50" to see what your issue is.

Thanks!

'show log security' does not show useful information. 'show log system' shows this:

Nov 8 09:28:54 :303022: <WARN> |AP 94:b4:0f:c5:e4:24@10.109.199.203 nanny| Reboot Reason: AP rebooted Sat Jan 1 00:08:50 UTC 2000; Image Upgrade Successful
Nov 8 09:46:33 :303022: <WARN> |AP 94:b4:0f:c5:e4:24@10.109.199.203 nanny| Reboot Reason: No reboot message found.
Nov 8 09:53:52 :303022: <WARN> |AP 94:b4:0f:c5:e4:24@10.109.199.203 nanny| Reboot Reason: No reboot message found.
Nov 8 10:00:05 :303022: <WARN> |AP 94:b4:0f:c5:e4:24@10.109.199.203 nanny| Reboot Reason: No reboot message found.
Nov 8 10:46:08 :303022: <WARN> |AP 94:b4:0f:c5:e4:24@10.109.199.203 nanny| Reboot Reason: AP rebooted Fri Dec 31 16:45:32 PST 1999; SAPD: Unable to contact switch: HELLO-TIMEOUT. Last rebootstrap reason: HELLO-TIMEOUT, 228 sec before: Last Ctrl msg: HELLO len=1205 dest=10.82.16.134 tries=10 seq=0
Nov 8 11:28:14 :399816: <4354> <ERRS> |activate| Activate Whitelist Download Service Failed. Reason:No login credentials. Cannot initiate a request

Do you see the access point in "show ap database"?

No, the AP does not appear at 'show ap database' listing

Any idea?

Are you certain the traffic between the AP and the controller is allowed? I.e you are permitted CPSEC through the firewall? The logs show the upgrade was successful so the next step is to establish CPSEC to the controller. Do you have any ACL's on your controller interfaces? Are you able to run a tcpdump between the AP and the controller to see which side is failing to reach the other?

Solved. Finally the problem was caused by a stupid configuration but I think some thoughts could be interesting por somebody:

The problem was an incorrect configuration of the default system profile. Despite of the fact the AP was properly whitelisted, with an assigned AP-group that was properly configured, together with its system profile, the default system profile was wrong. This caused the AP was assigned to a default AP group and the AP travelled to 'nowhere'. Possible improvement: If there were some message, either on the AP console side, either on the controller side logs, informing about the assigned lms controller, this problem could be easily solved, because, in my opinion, there is not enough information to guess what was happening or, at least, not easily accesible.

Other thinking about this issue: The system profile configuration was wrong because this controller's connectivity had been reconfigured. The problematic APs were associated at a first moment to this controller (besides the bad configuration), but at a later moment, the provisioned AP database was deleted. This probably caused the assignment to the default system profile on booting. Logs indicating a first discovery of an access point, not explicitily provisiones would be appreciated.