Can anyone say what's going on from the following log entry from an AP:

16:09:25 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
16:09:25 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
16:09:25 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
16:09:25 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
16:09:25 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
16:15:58 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
16:15:58 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
16:15:58 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
16:15:58 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
16:15:58 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
16:22:29 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
16:22:29 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
16:22:29 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
16:22:29 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
16:22:29 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
16:22:29 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
16:22:29 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
16:22:29 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
16:22:29 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
16:22:29 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
16:29:00 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
16:29:00 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
16:29:00 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
16:29:00 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
16:29:00 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
16:29:00 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
16:29:00 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
16:29:00 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
16:29:00 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
16:29:00 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
16:42:05 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
16:42:05 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
16:42:05 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
16:42:05 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
16:42:05 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
16:42:05 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
16:42:05 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
16:42:05 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
16:42:05 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
16:42:05 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected

A client that's already connected tries to associate, is disconnected, accepted and connected again twice within a second. And a few minutes later does it again.

The client is a RB433 running RouterOS 3.20, and reports Tx/Rx of -71/-65, signal to noise of 33dB and a CCQ in the 90% range. The AP is an RB532A running ROS v3.10

Every six minutes 31 seconds, or some multiple thereof!

16:48:38 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
16:48:38 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
16:48:38 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
16:48:38 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
16:48:38 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
> 6m 31s
16:55:09 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
16:55:09 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
16:55:09 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
16:55:09 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
16:55:09 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
16:55:09 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
16:55:09 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
16:55:09 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
16:55:09 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
16:55:09 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
> 6m 31s
17:01:40 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
17:01:40 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
17:01:40 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
17:01:40 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
17:01:40 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
> 6m 31s
17:08:12 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
17:08:12 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
17:08:12 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
17:08:12 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
17:08:12 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
> 6m 31s
17:14:43 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
17:14:43 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
17:14:43 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
17:14:43 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
17:14:43 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
> 13m 03s
17:27:46 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
17:27:46 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
17:27:46 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
17:27:46 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
17:27:46 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
> 13m 03s
17:40:49 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
17:40:49 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
17:40:49 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
17:40:49 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
17:40:49 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
> 6m 30s
17:47:19 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
17:47:19 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
17:47:19 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
17:47:19 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
17:47:19 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
> 6m 32s
17:53:51 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
17:53:51 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
17:53:51 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
17:53:51 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
17:53:51 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
> 6m 30s
18:00:21 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
18:00:21 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
18:00:21 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
18:00:21 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
18:00:21 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
> 13m 04s
18:13:25 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
18:13:25 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
18:13:25 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
18:13:25 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
18:13:25 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
18:13:25 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
18:13:25 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
18:13:25 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
18:13:25 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
18:13:25 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
> 13m 01s
18:26:26 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
18:26:26 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
18:26:26 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
18:26:26 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
18:26:26 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
> 26m 04s
18:52:31 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
18:52:31 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
18:52:31 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
18:52:31 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
18:52:31 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
> 6m 31s
18:59:02 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
18:59:02 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
18:59:02 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
18:59:02 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
18:59:02 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected

I had a similar problem, just not quite as often. On the station end, I found these log entries. This is a RouterBoard router. Entries in bold are added by the wireless logging.

jan/14 02:46:53 wireless,info 00:0C:42:60:F9:CE@wlan1: lost connection, no beacons received
jan/14 02:46:55 wireless,debug wlan1: must select network
jan/14 02:46:55 wireless,debug 00:0C:42:60:F9:CE: on 5825 AP: yes SSID WiFiBridgeMain caps 0x421 rates 0xff00 basic 0x100 MT: yes
jan/14 02:46:55 wireless,debug 00:0C:42:23:32:A0: on 5745 AP: yes SSID WiFiBridge1 caps 0x421 rates 0xff00 basic 0x100 MT: yes
jan/14 02:46:55 wireless,info 00:0C:42:60:F9:CE@wlan1 established connection on 5825, SSID WiFiBridgeMain

On my station routers, I entered the mac of the AP in the connect-list and set "default-authentication=no" on the station. All disconnects stopped.

Apparently when the AP starts to get busy, the ssid is not sent often enough for the station, so the station tries to find a better connection.

Thanks Surfer Tim.

As the AP's log reads it makes no sense at all - the client seems to want to associate with the AP while it's still connected so the AP has to disconnect it in order to let it instantly re-connect. If the log entries are out of order it might be that the client actively disconnects and instantly re-associates but there's no reason given for the active disconnection.

The client's log showed what you were getting and the AP was already in the connect list, but I've limited the interface scan to the AP's frequency and unselected default authentication as you suggest, and I'll report if it works or not.

No other CPE was showing the same behaviour and this wasn't the worst for signal.

What might be underlying the 6.5min intervals, though?

Quick comment about this type of log/wireless connectivity actions.

The logs can barely keep up with the reg re-reg intervals, so dont think about that. Whenever I see something like this, IMHO it is interference. Be advised that the interference can be at either end. If that is the only connection experiencing this behaviour, there could be client side interference, likely very nearby the CPE. I have seen local 802.11a APs that a customer sets up destroy a previously rock solid connection. Reg/re-reg is usually attributable to an interference condition. Seems like trying to attribute it to anything else is usually futile.

Just my two cents as elucidation that might help you identify conditions that can cause these anomalous conditions. Very frustrating when you operate on a frequency, and suddenly one customer goes this way...

@tombrdfrd66: Let me know how it works. I am interested if it works as well for you as it did me. I am not saying the action the station is taking is correct. It is just the way it appears to be.

I see no noise here. Signal at -50db, noise floor at -98db to -102db. I would think that if it were noise, I would still get interruptions in service, like disconnects with the "extensive data loss" message, and the connection would not be established again so quickly after the disconnect. Instead, the status in "/interface wireless registration-table" shows that my "noisy" connection has not been interrupted for 3w5d23h14m23s.

@tombrdfrd66: Let me know if that worked for you. I am in contact with Mikrotik support, and may need some additional input. Support says that change should not make a difference with that problem.

ADD: This is EXACTLY what happens when YOU do not respond when asked. Then, eventually, you will come back here and complain. Why should I bother? My system is working!

tombrdfrd66 Did this solution also work for you? I have just made the changes, but am anxious to know.

Hi guys. Apologies for not responding - I take your point ST. Unfortunately this suddenly came to be a rather minor problem in my life and I've only recently been able to get back on track.

And for what it's worth the problem/solution appeared to be that unbeknownst to me the subscriber installed a bog-standard SOHO wireless router in his home between the PC and CPE in order than his kids could connect via their laptops, and the default frequency of the SOHO router was the same as the CPE. Changing it seems to have stopped the disconnects.

Hi guys. Apologies for not responding - I take your point ST. Unfortunately this suddenly came to be a rather minor problem in my life and I've only recently been able to get back on track.

And for what it's worth the problem/solution appeared to be that unbeknownst to me the subscriber installed a bog-standard SOHO wireless router in his home between the PC and CPE in order than his kids could connect via their laptops, and the default frequency of the SOHO router was the same as the CPE. Changing it seems to have stopped the disconnects.

I use a program called WirelessMon - http://www.wirelessmon.com/ which scans depending on installed radio card in the laptop with do both 2.4/5.8 bands and is a quick way to check for co-channel or channel usage.

I use a program called WirelessMon - http://www.wirelessmon.com/ which scans depending on installed radio card in the laptop with do both 2.4/5.8 bands and is a quick way to check for co-channel or channel usage.

Thanks. I'll give it a go.

Actually the problem/solution was pretty obvious once I actually visited the subscriber's property but it was damn difficult to solve remotely as running a scan on the subscriber's CPE - which would have picked up the SOHO router's beacons - also cuts me off. Is there any way of running a scan remotely, perhaps using a script or watchdog, which stops the scan and re-establishes the connection without losing the scan's results?

I use a program called WirelessMon - http://www.wirelessmon.com/ which scans depending on installed radio card in the laptop with do both 2.4/5.8 bands and is a quick way to check for co-channel or channel usage.

Thanks. I'll give it a go.

Actually the problem/solution was pretty obvious once I actually visited the subscriber's property but it was damn difficult to solve remotely as running a scan on the subscriber's CPE - which would have picked up the SOHO router's beacons - also cuts me off. Is there any way of running a scan remotely, perhaps using a script or watchdog, which stops the scan and re-establishes the connection without losing the scan's results?

There is few commands that can be run from a mac-telnet session can only be very short in duration less than 10seconds before wireless disconnects, many users would like and have requested as a important feature storing to file a remote wireless scan on MT which can be opened on re-establishing wireless connection after the scan.