Wireless Access

We have two sites that are linked via two AP 60s with external aerials. These AP's have been setup as a mesh in order to extend the site to another building.

This has been up and running for the past 3 years but now the link between the two sites keeps dropping

When I look at the logs we keep seeing

Oct  9 05:08:55  nanny[139]: <303022> <WARN> |AP Start_Hill_AP@10.233.82.202 nanny|  Reboot Reason: AP rebooted Tue Oct 9 14:07:08 BST 2012: SAPD: Unable to contact switch. Called by sapd_keepalive_cb:4462

Oct  9 05:14:34  nanny[139]: <303022> <WARN> |AP Start_Hill_AP@10.233.82.202 nanny|  Reboot Reason: AP rebooted Tue Oct 9 14:12:26 BST 2012: SAPD: Unable to contact switch. Called by sapd_ap_ready_cb:3142

The Start_Hill AP is connected directly to the controller so we can't understand why it keeps rebooting.

They are running software version 3.4.0.4

Can anyone suggest anything?

Check the ethernet interface where Start_hill is connected to make sure the AP negotiated the correct speed and duplex on that port.

I have checked the port and it is connected at 100mbs full duplex. The port is set to Auto speed and auto duplex.

There are no errors either.  However the controller was rebooted yesterday and the cabling to the AP changed.

There are two CAT5 cables that have been run from the AP to the comms room.

At the AP end, the cable is terminated with an RJ45 (so it can plug directly into the AP). At the other end the cables are terminated onto RJ45 sockets and then a patch lead from the socket to the controller.

If the only thing that was changed is the cable, I want to say, please test the cable.

Are you powering the AP with a power injector?  What type and what is the length of the cable?

We only changed the cable in an attempt to fix the problem.

Both AP's are being powered by PoE. The one connected to the controller is using one of the PoE ports on that. The AP is approximately 35mtrs from the controller

The other is getting it's PoE from the network switch installed. This is a distance of approximately 10 mtrs. This switch is also providing PoE to the IP phones installed there.

The phones are using the Mesh to get back to the telephone system at the head office (where the Start_Hill AP is located).

While that access point is connected see if it is missing any heartbeats.  On the commandline, type:

show ap debug system-status ip-addr <ip sddress of ap> | begin Heartbeat

Heartbeat Stats
---------------
Heartbeats Sent  Heartbeats Received  Measurement Duration
---------------  -------------------  --------------------
382489           379275               since last rebootstrap
382489           379275               total since bootup

I have run the command for both AP's and they are saying 0 sent and 0 received

Can you ping the AP from the controller?

What provides DHCP to the AP, or is it statically addressed?

What does the access point use to discover the controller?  DNS, DHCP, Broadcast?

When you type "show ap database", what is the last ip address that the AP ever got?

Yes we can ping the APs from the controller.

The IP addresses have been statically assigned to the APs

The APs discovered the controller (initially) through a broadcast but have been provisioned with the IP address of the controller.

The last point is irrelevant as the IP addresses are statically assigned.

We have checked to make sure that there are no other devices on the network with the same IP address and that the IP addresses are in the exclusion list of the DHCP server.

Also this is not happening all the time but we have ruled out staff equipment and even salesmen laptops which are plugged in periodically throughout the week.

Duplicate ip address is usually the only answer.  Try to change the IP address and see if that helps.

It appears that they had not put the IP addresses in the exclusion list in the DHCP server.

The IP address for the controller ends in 200 and the APs end in 202 and 203

They have now done this and we now waiting to see if the problem re-occurs but personally I think that this was the problem.

Thanks for all your help and hopefully this is the last we will hear of it.