Wireless NV2 messages explanation please!!!

WirelessRudy · Tue Jun 28, 2011 2:32 am

we still have not an updated version of the http://wiki.mikrotik.com/wiki/Wireless_Debug_Logs
document.

Since ros5.4 still has the disconnection issue it is really important to have a full list of all messages that both AP and client can produce in relation to the NV2 protocol to trouble shoot why links are dropping.
Apart from knowing what they actually mean, we also need to know what triggers which message;

For instance:
AP:
1) "disconnected, control frame time out"
2) "disconnected, not responding"
3) "disconnected, disabling"
4) "disconnected, access-list changed"
5) "reconnecting"
6) "connected"

Some clients are first "connected" and than "reconnecting", sometimes several times in the same minute.
some clients are "disconnected, access-list changed" while this is definitely NOT the case!

Station:
1) "disconnected, not responding"
2) "disconnected, control frame timeout"
3) "lost connection, control frame timeout"
4) "lost connection, synchronization timeout"
5) "lost connection, medium-access timeout"
6) "failed to connect, on xxxx, synchronization timeout"
7) "failed to connect, on xxx, not allowed"

"reconnecting"

All my 250+ units run v5.4 now with updated firmwares and are routerboards with MT radio cards.
On some 225 stations I have still roughly 5% units showing all kinds of disconnections followed by connections etc.
I have done all to my present knowledge to ´harden´ links and avoid interferences (see many of my other posts) but some units just keep on disconnecting while all parameters actually tell me the link is of high quality!
I know I am not the only one still struggling with this issue. We need to have good understanding of all these different messages in one document to help us troubleshooting and finding solutions.
If MT says they can't reproduce, they at least should give us insight in the NV2 messaging process so we as operator can do the troubleshooting ourselves. I do have "Un-sollicited MT beta tester" printed on my badge!

Please MT (and/or other ´guru's on this forum) can we make this list happen asap!
If we don't get the "disconnections" issues under control in ros 5.x NV2 MT might as well abandon the whole NV2! And we as users abandon MT!

WirelessRudy · Tue Jun 28, 2011 2:40 am

And to add to the "NV2" issue:

I have units with ´ghost´ disconnects (see http://forum.mikrotik.com/viewtopic.php ... 24#p269024)
Issue is that IP flow disconnects where ping, and log and register show the connectivity is never lost.

I also have units that according the log are disconnected and re-connected but register doesn't show anything on client and AP and Skype conversations don't notice!
(Here it looks like the messaging system of NV2 is a bit too sensitive!)

Since two days I suddenly have an AP that disconnects once a day all clients at once to connect them all backup in the same minute. This AP already runs for 2 months now with latest ros5.x versions and NV2 (5Ghz-10Mhz) and was really doing fine. Now I'm back troubleshooting again.....

WirelessRudy · Tue Jun 28, 2011 12:55 pm

No reply???

Does this mean everybody knows? Or nobody knows?

SurferTim · Tue Jun 28, 2011 1:31 pm

Hi WirelessRudy! We meet again on this same subject. A lot of people know about the problem, but nobody "knows" a reliable fix. It may involve more than one cause. In my case, the station was apparently trying to roam to another ap-bridge nearby.

Take a look at this post.
http://forum.mikrotik.com/viewtopic.php?f=7&t=49306

Have you set verbose logging on your station router?

/system logging
add topics=wireless,debug action=memory

See if your station is trying to roam. If it is, you will see entries like this:

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

I had already entered the mac address of the ap-bridge in the station connect-list when I copied this section of log, so the line about "no match in connect list" is missing.

ADD: The patent on Spread Spectrum Technology (held by Hedy Lamarr) is based on traffic on the frequency, not signal strength. It was originally designed to circumvent the torpedo jamming devices employed by the Japanese in WW2, but is now used for cell phones and wireless devices.

n21roadie · Tue Jun 28, 2011 3:00 pm

.....................
If MT says they can't reproduce, they at least should give us insight in the NV2 messaging process so we as operator can do the troubleshooting ourselves. I do have "Un-sollicited MT beta tester" printed on my badge!

Please MT (and/or other ´guru's on this forum) can we make this list happen asap!
If we don't get the "disconnections" issues under control in ros 5.x NV2 MT might as well abandon the whole NV2! And we as users abandon MT!

If MK say they cannot reproduce the issue, why?

Is it a combination of hardware + software+ local signal factors?

I don't think the issue with NV2 is simpy software based but a combination of several variables?

At present we (Wisps) use a variety of different AP antenna's + radio cards+ Rf leads at our sites is this is a contributing factor, if MK produced a professional integrated AP antenna and tested new software on this unit(s), this could reduce some variables in the current mix?

WirelessRudy · Tue Jun 28, 2011 5:29 pm

.....................
If MT says they can't reproduce, they at least should give us insight in the NV2 messaging process so we as operator can do the troubleshooting ourselves. I do have "Un-sollicited MT beta tester" printed on my badge!

Please MT (and/or other ´guru's on this forum) can we make this list happen asap!
If we don't get the "disconnections" issues under control in ros 5.x NV2 MT might as well abandon the whole NV2! And we as users abandon MT!
If MK say they cannot reproduce the issue, why?

Is it a combination of hardware + software+ local signal factors?

I don't think the issue with NV2 is simpy software based but a combination of several variables?

At present we (Wisps) use a variety of different AP antenna's + radio cards+ Rf leads at our sites is this is a contributing factor, if MK produced a professional integrated AP antenna and tested new software on this unit(s), this could reduce some variables in the current mix?

I can understand MT cannot reproduce issues at times. Each network is different and it is impossible to make a ´mirror´ of a network somewhere else.
On the other hand, I use only MT hardware with only MT radio cards and updated ROS to 5.4 with latest firmwares. If now their own product can't even perform 100% I would be worried if I was MT

But that all doesn't mean they can't supply us the info we need. Messages produced by the software have to be triggered by some events or behaviour and should give information where what and why went wrong...

The Wiki wireless debug log messages document is only valid for the normal 802.11 protocol. MT works already a year I believe with NV2 and still we haven't seen any manual explaining all the different messages it can produce.
Now it still has so many problems It is really needed!

Like said, I can understand MT can't always put the finger on the spot of an issue in networks far beyond their reach. But at least they should help us troubleshooting by giving us the proper tools....

n21roadie · Tue Jun 28, 2011 6:05 pm

...........................I can understand MT cannot reproduce issues at times. Each network is different and it is impossible to make a ´mirror´ of a network somewhere else.
On the other hand, I use only MT hardware with only MT radio cards and updated ROS to 5.4 with latest firmwares. If now their own product can't even perform 100% I would be worried if I was MT

But that all doesn't mean they can't supply us the info we need. Messages produced by the software have to be triggered by some events or behaviour and should give information where what and why went wrong...

The Wiki wireless debug log messages document is only valid for the normal 802.11 protocol. MT works already a year I believe with NV2 and still we haven't seen any manual explaining all the different messages it can produce.
Now it still has so many problems It is really needed!

Like said, I can understand MT can't always put the finger on the spot of an issue in networks far beyond their reach. But at least they should help us troubleshooting by giving us the proper tools....

OK - But do you use MK antenna's - If MK had intergrated AP's antenna's then they could say NV2 was tested using ....
Also from testing such a unit(s) they could recommend minimum antenna physical seperation or rule out such physical seperation is required for optimum NV2 usage in multi AP's + Ptp's being used on a mast.

Also i tried 5.4 with NV2 and had to go back to 4.17 as new clients were associating but not transfering data?

WirelessRudy · Tue Jun 28, 2011 6:26 pm

Ok, this is what I get:

Jun /28/2011 16:10:21 wireless info 00:0C:42:61:EE:D6@wlan1: lost connection, medium-access timeout
Jun /28/2011 16:10:21 wireless debug wlan1: must select network
Jun /28/2011 16:10:21 wireless debug empty
Jun /28/2011 16:10:21 wireless debug wlan1: no network that satisfies connect-list, by default do not connect
Jun /28/2011 16:10:21 wireless debug wlan1: must select network
Jun /28/2011 16:10:21 wireless debug empty
Jun /28/2011 16:10:21 wireless debug wlan1: no network that satisfies connect-list, by default do not connect
Jun /28/2011 16:10:21 wireless debug wlan1: must select network
Jun /28/2011 16:10:21 wireless debug empty
Jun /28/2011 16:10:21 wireless debug wlan1: no network that satisfies connect-list, by default do not connect
Jun /28/2011 16:10:21 wireless debug wlan1: failed to select network
Jun /28/2011 16:10:21 wireless debug wlan1: delaying scanning
Jun /28/2011 16:10:24 wireless debug wlan1: must select network
Jun /28/2011 16:10:24 wireless debug empty
Jun /28/2011 16:10:24 wireless debug wlan1: no network that satisfies connect-list, by default do not connect
Jun /28/2011 16:10:24 wireless debug wlan1: must select network
Jun /28/2011 16:10:24 wireless debug empty
Jun /28/2011 16:10:24 wireless debug wlan1: no network that satisfies connect-list, by default do not connect
Jun /28/2011 16:10:24 wireless debug wlan1: must select network
Jun /28/2011 16:10:24 wireless debug empty
Jun /28/2011 16:10:24 wireless debug wlan1: no network that satisfies connect-list, by default do not connect
Jun /28/2011 16:10:24 wireless debug wlan1: failed to select network
Jun /28/2011 16:10:24 wireless debug wlan1: delaying scanning
Jun /28/2011 16:10:27 wireless debug wlan1: must select network
Jun /28/2011 16:10:27 wireless debug empty
Jun /28/2011 16:10:27 wireless debug wlan1: no network that satisfies connect-list, by default do not connect

This goes on every 3 secs until:
Jun /28/2011 16:10:39 wireless debug wlan1: must select network
Jun /28/2011 16:10:39 wireless debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun /28/2011 16:10:39 wireless debug 00:0C:42:61:EE:D6@wlan1 established connection on 5700, SSID MarComE

Unit is now connected for about 37 minutes and the whole sequence starts again....

the message "no network that satisfies connect-list, by default do not connect" imho can only be explained by two things: 1. router does not have the network it ´hears´ in the ´connect to´ list. Which is not the case, it is...
2. router ´hears´ the network he is listening to not good enough. The SSID becomes scrambled, distorted or whatever, anyway beyond a level where radio can determine if this is the network he should be listening too.

Reason 2 is probably what is happening. Somewhere else in the regin same frequency is used by an AP (with different SSID) and although AP can't hear it, this client possibly can. But this client ´hears´ its designed SSID with some -71dBm where that other network must be somewhere in the region of -90dBm or worse.

I can only imagine that sometimes traces of that other AP must come in at stronger levels and thus create the problem. But both this and distant AP and this client run NV2 This should basically avoid such problems...?

WirelessRudy · Tue Jun 28, 2011 6:31 pm

@n21roadie;

As you can read, I only use MT hardware and that means in 60% of the cases also MT antenna (RIC units with rb133c3 or rb4119)
The problem however is spread over all types of hardware (differet routerboards, some RIC unist, some with other vendor casings, some just plastic, some perfect shielded metal boxes.)

What do you mean with "MK"? I always presume you just typed "MT" like that? Is this another brand?

WirelessRudy · Tue Jun 28, 2011 6:44 pm

In regard to the unit I just print a part of the log;

I have a winbox session open to it, with the log messaging window open.
I see in the log the unit is disconnecting with all its messages.
According the log from disconnect to finally re-association takes 12 secs.
All this time the winbox (and thus the real data stream to that remote unit) is not lost!

So, although log shows disconnects for up to 12 secs, the unit just stays online! How is that!

WirelessRudy · Tue Jun 28, 2011 9:12 pm

Please read the bottom...

Jun/28/2011 17:50:52 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 17:50:52 wireless,debug wlan1: failed to select network
Jun/28/2011 17:50:52 wireless,debug wlan1: delaying scanning
Jun/28/2011 17:50:55 wireless,debug wlan1: must select network
Jun/28/2011 17:50:55 wireless,debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun/28/2011 17:50:55 wireless,debug wlan1: 00:0C:42:61:EE:D6 failed to join recently
Jun/28/2011 17:50:55 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 17:50:55 wireless,debug wlan1: must select network
Jun/28/2011 17:50:55 wireless,debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun/28/2011 17:50:55 wireless,debug wlan1: 00:0C:42:61:EE:D6 uses TDMA, skip
Jun/28/2011 17:50:55 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 17:50:55 wireless,debug wlan1: must select network
Jun/28/2011 17:50:55 wireless,debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun/28/2011 17:50:55 wireless,debug wlan1: 00:0C:42:61:EE:D6 uses TDMA, skip
Jun/28/2011 17:50:55 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 17:50:55 wireless,debug wlan1: failed to select network
Jun/28/2011 17:50:55 wireless,debug wlan1: delaying scanning
Jun/28/2011 17:50:58 wireless,debug wlan1: must select network
Jun/28/2011 17:50:58 wireless,debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun/28/2011 17:50:58 wireless,debug wlan1: 00:0C:42:61:EE:D6 failed to join recently
Jun/28/2011 17:50:58 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 17:50:58 wireless,debug wlan1: must select network
Jun/28/2011 17:50:58 wireless,debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun/28/2011 17:50:58 wireless,debug wlan1: 00:0C:42:61:EE:D6 uses TDMA, skip
Jun/28/2011 17:50:58 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 17:50:58 wireless,debug wlan1: must select network
Jun/28/2011 17:50:58 wireless,debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun/28/2011 17:50:58 wireless,debug wlan1: 00:0C:42:61:EE:D6 uses TDMA, skip
Jun/28/2011 17:50:58 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 17:50:58 wireless,debug wlan1: failed to select network
Jun/28/2011 17:50:58 wireless,debug wlan1: delaying scanning
Jun/28/2011 17:51:01 wireless,debug wlan1: must select network
Jun/28/2011 17:51:01 wireless,debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun/28/2011 17:51:01 wireless,debug wlan1: 00:0C:42:61:EE:D6 failed to join recently
Jun/28/2011 17:51:01 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 17:51:01 wireless,debug wlan1: must select network
Jun/28/2011 17:51:01 wireless,debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun/28/2011 17:51:01 wireless,debug wlan1: 00:0C:42:61:EE:D6 uses TDMA, skip
Jun/28/2011 17:51:01 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 17:51:01 wireless,debug wlan1: must select network
Jun/28/2011 17:51:01 wireless,debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun/28/2011 17:51:01 wireless,debug wlan1: 00:0C:42:61:EE:D6 uses TDMA, skip
Jun/28/2011 17:51:01 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 17:51:01 wireless,debug wlan1: failed to select network
Jun/28/2011 17:51:01 wireless,debug wlan1: delaying scanning
Jun/28/2011 17:51:04 wireless,debug wlan1: must select network
Jun/28/2011 17:51:04 wireless,debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun/28/2011 17:51:04 wireless,info 00:0C:42:61:EE:D6@wlan1 established connection on 5700, SSID MaruComE
Jun/28/2011 18:10:36 wireless,info 00:0C:42:61:EE:D6@wlan1: lost connection, medium-access timeout
Jun/28/2011 18:10:36 wireless,debug wlan1: must select network
Jun/28/2011 18:10:36 wireless,debug empty
Jun/28/2011 18:10:36 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 18:10:36 wireless,debug wlan1: must select network
Jun/28/2011 18:10:36 wireless,debug empty
Jun/28/2011 18:10:36 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 18:10:36 wireless,debug wlan1: must select network
Jun/28/2011 18:10:36 wireless,debug empty
Jun/28/2011 18:10:36 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 18:10:36 wireless,debug wlan1: failed to select network
Jun/28/2011 18:10:36 wireless,debug wlan1: delaying scanning
Jun/28/2011 18:10:39 wireless,debug wlan1: must select network
Jun/28/2011 18:10:39 wireless,debug empty
Jun/28/2011 18:10:39 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 18:10:39 wireless,debug wlan1: must select network
Jun/28/2011 18:10:39 wireless,debug empty
Jun/28/2011 18:10:39 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 18:10:39 wireless,debug wlan1: must select network
Jun/28/2011 18:10:39 wireless,debug empty
Jun/28/2011 18:10:39 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 18:10:39 wireless,debug wlan1: failed to select network
Jun/28/2011 18:10:39 wireless,debug wlan1: delaying scanning
Jun/28/2011 18:10:42 wireless,debug wlan1: must select network
Jun/28/2011 18:10:42 wireless,debug empty
Jun/28/2011 18:10:42 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 18:10:42 wireless,debug wlan1: must select network
Jun/28/2011 18:10:42 wireless,debug empty
Jun/28/2011 18:10:42 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 18:10:42 wireless,debug wlan1: must select network
Jun/28/2011 18:10:42 wireless,debug empty
Jun/28/2011 18:10:42 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 18:10:42 wireless,debug wlan1: failed to select network
Jun/28/2011 18:10:42 wireless,debug wlan1: delaying scanning
Jun/28/2011 18:10:45 wireless,debug wlan1: must select network
Jun/28/2011 18:10:45 wireless,debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun/28/2011 18:10:45 wireless,info 00:0C:42:61:EE:D6@wlan1 established connection on 5700, SSID MaruComE
Jun/28/2011 18:46:22 wireless,info 00:0C:42:61:EE:D6@wlan1: lost connection, medium-access timeout
Jun/28/2011 18:46:22 wireless,debug wlan1: must select network
Jun/28/2011 18:46:22 wireless,debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun/28/2011 18:46:22 wireless,info 00:0C:42:61:EE:D6@wlan1 established connection on 5700, SSID MaruComE
Jun/28/2011 19:03:10 wireless,info 00:0C:42:61:EE:D6@wlan1: lost connection, medium-access timeout
Jun/28/2011 19:03:11 wireless,debug wlan1: must select network
Jun/28/2011 19:03:11 wireless,debug empty
Jun/28/2011 19:03:11 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 19:03:11 wireless,debug wlan1: must select network
Jun/28/2011 19:03:11 wireless,debug empty
Jun/28/2011 19:03:11 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 19:03:11 wireless,debug wlan1: must select network
Jun/28/2011 19:03:11 wireless,debug empty
Jun/28/2011 19:03:11 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 19:03:11 wireless,debug wlan1: failed to select network
Jun/28/2011 19:03:11 wireless,debug wlan1: delaying scanning
Jun/28/2011 19:03:14 wireless,debug wlan1: must select network
Jun/28/2011 19:03:14 wireless,debug empty
Jun/28/2011 19:03:14 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 19:03:14 wireless,debug wlan1: must select network
Jun/28/2011 19:03:14 wireless,debug empty
Jun/28/2011 19:03:14 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 19:03:14 wireless,debug wlan1: must select network
Jun/28/2011 19:03:14 wireless,debug empty
Jun/28/2011 19:03:14 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 19:03:14 wireless,debug wlan1: failed to select network
Jun/28/2011 19:03:14 wireless,debug wlan1: delaying scanning
Jun/28/2011 19:03:17 wireless,debug wlan1: must select network
Jun/28/2011 19:03:17 wireless,debug empty
Jun/28/2011 19:03:17 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 19:03:17 wireless,debug wlan1: must select network
Jun/28/2011 19:03:17 wireless,debug empty
Jun/28/2011 19:03:17 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 19:03:17 wireless,debug wlan1: must select network
Jun/28/2011 19:03:17 wireless,debug empty
Jun/28/2011 19:03:17 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 19:03:17 wireless,debug wlan1: failed to select network
Jun/28/2011 19:03:17 wireless,debug wlan1: delaying scanning
Jun/28/2011 19:03:20 wireless,debug wlan1: must select network
Jun/28/2011 19:03:20 wireless,debug empty
Jun/28/2011 19:03:20 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 19:03:20 wireless,debug wlan1: must select network
Jun/28/2011 19:03:20 wireless,debug empty
Jun/28/2011 19:03:20 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 19:03:20 wireless,debug wlan1: must select network
Jun/28/2011 19:03:20 wireless,debug empty
Jun/28/2011 19:03:20 wireless,debug wlan1: no network that satisfies connect-list, by default do not connect
Jun/28/2011 19:03:20 wireless,debug wlan1: failed to select network
Jun/28/2011 19:03:20 wireless,debug wlan1: delaying scanning
Jun/28/2011 19:03:23 wireless,debug wlan1: must select network
Jun/28/2011 19:03:23 wireless,debug 00:0C:42:61:EE:D6: on 5700 AP: no SSID MaruComE caps 0x0 rates 0x0 basic 0x0 MT: no
Jun/28/2011 19:03:23 wireless,info 00:0C:42:61:EE:D6@wlan1 established connection on 5700, SSID MaruComE
Jun/28/2011 19:03:33 system,info,account user adminrudy logged out from 172.25.48.4 via winbox
Jun/28/2011 19:13:19 system,info,account user adminrudy logged in from 172.25.48.4 via winbox

Qustions:

What does the “MT: no” mean?
Why “uses TDMA, skip”? Off course the AP uses TDAM (=NV2), so why “skip”?
What does the “empty” mean? What is empty?

Also, notice that the message "uses TDMA, skip" after a connection at 17:51:04 dissapears from the log. Instead we now suddenly get a message "empty"?

SurferTim · Tue Jun 28, 2011 9:50 pm

I asked support@mikrotik.com about that wireless debug info last month. This was the response:

Hello,

We are not providing this information to the customers as it is a debug information.

Regards,
Uldis

n21roadie · Tue Jun 28, 2011 10:53 pm

@n21roadie;

As you can read, I only use MT hardware and that means in 60% of the cases also MT antenna (RIC units with rb133c3 or rb4119)
The problem however is spread over all types of hardware (differet routerboards, some RIC unist, some with other vendor casings, some just plastic, some perfect shielded metal boxes.)

What do you mean with "MK"? I always presume you just typed "MT" like that? Is this another brand?

Mk = Mikrotik normally i use MT (sorry)

My issue with NV2 is with multi AP's on a mast, my temp solution for now was to mix the use of each AP NV2 or 802.11, and hopefully over the next few weeks i will be able to work on this as a process of elimination of any proximity effect of the AP's + PtP's,

Strange from reading that NV2 regards other signals (802.11..) as noise, this should be a operational advantage but is it really?

One item which is on my must have list, is a sprectrum anaylzer only then can one rule out interference

Like said, I can understand MT can't always put the finger on the spot of an issue in networks far beyond their reach. But at least they should help us troubleshooting by giving us the proper tools....

I asked support@mikrotik.com about that wireless debug info last month. This was the response:
Hello,

We are not providing this information to the customers as it is a debug information.

Regards,
Uldis

I have a question has MT ruled out configuration issues as the cause of these NV2 issues?

Mplsguy · Tue Jun 28, 2011 11:13 pm

What does the “MT: no” mean?

This is cosmetic, it will say "yes" only for 802.11&nstreme routeros APs.

Why “uses TDMA, skip”? Off course the AP uses TDAM (=NV2), so why “skip”?

This is more tricky. I guess you have "wireless-protocol=nv2-nstreme-802.11" on client. Here is what happens - station scans, gathers list of APs (scan results), then starts evaluating these results with respect to current configuration, to choose AP to connect to. At first it looks for suitable nv2 AP. Does not see it in scan results - ..:D6 is not acceptable, because client recently tried to connect and failed, so it will only consider it after time. Then client "switches" to nstreme mode and evaluates scan results. The only AP in scan results is not acceptable for nstreme (because it uses TDMA, hence the message), so nothing to do in nstreme mode, the same immediately happens for 802.11. You can notice that all those messages are printed at the same time, then client sleeps for a while and then starts scanning again.

What does the “empty” mean? What is empty?

Scan results are empty. Basically client writes "must select network" and then a list of APs it saw while scanning or "empty" if there are no results.

Also, notice that the message "uses TDMA, skip" after a connection at 17:51:04 dissapears from the log. Instead we now suddenly get a message "empty"?

Yes, because client for some reason does not see your AP any more. What is signal level and noise level as seen by client? Can you graph signal level and noise level during periods when client manages to connect to see if there is no some suspicios degradation over time?

As to "medium-access timeout" message - client disconnects with this message when it does not get timeslot from AP for some time period. This can be caused by multiple things, so it can be better explained in combination with relevant message on AP. Here are some possible causes:
- data loss in direction AP->client, client does not receive valid messages assigning timeslot to it
- data loss in direction client->AP, AP decides that client is dead, because it does not use its timeslots (actually maybe it does, but AP does not receive anything), throws it out and does not assign any timeslots.
- configuration changes/reset/reboot on AP when AP disconnects clients.

Updating wiki page with messages is on TODO list.

chadd · Wed Jun 29, 2011 1:52 am

Yes, because client for some reason does not see your AP any more. What is signal level and noise level as seen by client? Can you graph signal level and noise level during periods when client manages to connect to see if there is no some suspicios degradation over time?

As to "medium-access timeout" message - client disconnects with this message when it does not get timeslot from AP for some time period. This can be caused by multiple things, so it can be better explained in combination with relevant message on AP. Here are some possible causes:
- data loss in direction AP->client, client does not receive valid messages assigning timeslot to it
- data loss in direction client->AP, AP decides that client is dead, because it does not use its timeslots (actually maybe it does, but AP does not receive anything), throws it out and does not assign any timeslots.
- configuration changes/reset/reboot on AP when AP disconnects clients.

Updating wiki page with messages is on TODO list.

Mplsguy,

I am really not sure who does what at MT but I have been working with Uldis on and off for months regarding issues with NV2 and the new wireless package. I don't know how you guys are going to do it but you NEED to get these issues fixed. You can't expect people to continue to buy and use your products when there are glaring issues like this in the software/hardware. Just shrugging it off and saying "we can't reproduce the problem" isn't going to cut it.

I have given Uldis access to one of our AP's and a few clients that have issues with disconnects, I can't do anymore than that on my side unless someone at MT provides me with instructions on how to obtain the information you are looking for so I can forward it to you when the disconnects are happening. When you guys are looking at the AP/Clients it is in the middle of the night here and little to no traffic is flowing so disconnects are minimal to non-existent.

The clients have solid connections with signals in the -60's and CCQ in the 90-100% range yet they are still disconnecting regularly, there is a problem with NV2 like it or not, there are too many end users with the exact same problems reported on these forums and to support. It is hard telling how many are out there with the same problems that aren't reporting them.

The latest ticket is Ticket#2011052366000116

n21roadie · Wed Jun 29, 2011 2:14 am

Mplsguy,

I am really not sure who does what at MT but I have been working with Uldis on and off for months regarding issues with NV2 and the new wireless package. I don't know how you guys are going to do it but you NEED to get these issues fixed. You can't expect people to continue to buy and use your products when there are glaring issues like this in the software/hardware. Just shrugging it off and saying "we can't reproduce the problem" isn't going to cut it.

I have given Uldis access to one of our AP's and a few clients that have issues with disconnects, I can't do anymore than that on my side unless someone at MT provides me with instructions on how to obtain the information you are looking for so I can forward it to you when the disconnects are happening. When you guys are looking at the AP/Clients it is in the middle of the night here and little to no traffic is flowing so disconnects are minimal to non-existent.

The clients have solid connections with signals in the -60's and CCQ in the 90-100% range yet they are still disconnecting regularly, there is a problem with NV2 like it or not, there are too many end users with the exact same problems reported on these forums and to support. It is hard telling how many are out there with the same problems that aren't reporting them.

The latest ticket is Ticket#2011052366000116

Can i ask was there any system mis-configuration(s) on your AP's found by Uldis?

Have you found one sector AP is more prone to disconnects than other sector AP's,

I have noticed with a simple PTP (NV2) onto just 1 AP (NV2) has no disconnects but have sectors + Ptp links on a mast then some but all (AP's + Ptp) will have disconnects,

Also are you sure with unlicensed frequencies (i assume you are using) that signal interference on the is not somehow causing the disconnects,

WirelessRudy · Wed Jun 29, 2011 2:16 am

I asked support@mikrotik.com about that wireless debug info last month. This was the response:
Hello,

We are not providing this information to the customers as it is a debug information.

Regards,
Uldis

Well, that's a bold approach. It's like a car dealer selling you a car, you get engine problems on the road but back in the garage they can't reproduce these. Now you ask all about the board computer's warning messages that you get on the road and they deny the meaning of these? Why make the user able to read these than anyway?
If this is their approach I fear this issue is not going to be solved soon.....

WirelessRudy · Wed Jun 29, 2011 2:55 am

Finally some movement on this issue!

What does the “MT: no” mean?
This is cosmetic, it will say "yes" only for 802.11&nstreme routeros APs.

OK, so this is a normal message we should expect when using a client that scans for all three protocols. Since my AP is indeed NV2 the client should say "no" here.

Why “uses TDMA, skip”? Off course the AP uses TDAM (=NV2), so why “skip”?
This is more tricky. I guess you have "wireless-protocol=nv2-nstreme-802.11" on client. Here is what happens - station scans, gathers list of APs (scan results), then starts evaluating these results with respect to current configuration, to choose AP to connect to. At first it looks for suitable nv2 AP. Does not see it in scan results - ..6 is not acceptable, because client recently tried to connect and failed, so it will only consider it after time. Then client "switches" to nstreme mode and evaluates scan results. The only AP in scan results is not acceptable for nstreme (because it uses TDMA, hence the message), so nothing to do in nstreme mode, the same immediately happens for 802.11. You can notice that all those messages are printed at the same time, then client sleeps for a while and then starts scanning again.

OK again... Indeed, my client is set to "wireless-protocol=nv2-nstreme-802.11". Would this now mean that if I set my client to NV2 only this message dissapears and at the same time the scanning process for the protocols is skipped and client has an even faster change to connect to NV2 AP? (After all, AP is both with SSID and mac in the ´connect-to´ list, freq. scans is set for the AP freq. only so client is basically forced to listen to this specific AP only. If it still can't connect, other reasons for the disconnections come in place...., the onces explained later in this post?)

What does the “empty” mean? What is empty?
Scan results are empty. Basically client writes "must select network" and then a list of APs it saw while scanning or "empty" if there are no results.

When I have client set to ´listen´ on AP freq. only, and connect to AP's mac or SSID only (and off course def. auth is off) this would mean the client actually doesn't hear any signal of that AP?

Also, notice that the message "uses TDMA, skip" after a connection at 17:51:04 dissapears from the log. Instead we now suddenly get a message "empty"?
Yes, because client for some reason does not see your AP any more. What is signal level and noise level as seen by client? Can you graph signal level and noise level during periods when client manages to connect to see if there is no some suspicios degradation over time?

No, I have no graph tools setup to do so. But I look at two different units that both have the same problem very regurlarly (I have more but these are my ´troubleshooter´ units).
One unit has a relative stable signal around -71 for both tx/rx what can be a bit low for NV2.

The other unit has a very stable signal that is always around -51dBm. Noise floor is always better than -100 and CCQ almost always better than 95%. I can look at the status window of this client to see that both levels are not changing, even at the moment the log shows the unit is disconnecting.... (And the connection of winbox is not even lost! How is that???). All parameters are just rock solid..
This unit also have on the same radius from same AP but 5 mtrs beside him the same units running and they have not a single dissconnect for days.....
I can understand that this particular unit I troubleshoot might be in a very specific ´interference-spot`. When running a scan it ´sees´ another AP only 20Mhz away (bounced signal, their is actually a 10mtr high house block 20mtrs wide in between) at same strenght level. This other AP runs normal 802.11 though. When I switch this other AP to NV2 inmediately on both AP-client network I get a handfull units starting with disconnects.... while the issue is not going on this ´test´ unit.

As to "medium-access timeout" message - client disconnects with this message when it does not get timeslot from AP for some time period. This can be caused by multiple things, so it can be better explained in combination with relevant message on AP. Here are some possible causes:
- data loss in direction AP->client, client does not receive valid messages assigning timeslot to it
- data loss in direction client->AP, AP decides that client is dead, because it does not use its timeslots (actually maybe it does, but AP does not receive anything), throws it out and does not assign any timeslots.
- configuration changes/reset/reboot on AP when AP disconnects clients.

Ok, apart from the config changes/reboot/reset etc reason, what can be done to make sure these timeslots are better used and understood by client? All my networks are under 10km ranges, most even less than 500mtrs. Maybe NV2 is not really designed for such short distances?

Updating wiki page with messages is on TODO list.

But does it have any priority? We are basically offering you guys help to sort it to out to speed it up. But we need feed back. We are beeing used as beta testers anyway, give us a bit more feedback and we all benefit! This post is a good start....

WirelessRudy · Wed Jun 29, 2011 3:00 am

Mplsguy,

I am really not sure who does what at MT but I have been working with Uldis on and off for months regarding issues with NV2 and the new wireless package. I don't know how you guys are going to do it but you NEED to get these issues fixed. You can't expect people to continue to buy and use your products when there are glaring issues like this in the software/hardware. Just shrugging it off and saying "we can't reproduce the problem" isn't going to cut it.

I have given Uldis access to one of our AP's and a few clients that have issues with disconnects, I can't do anymore than that on my side unless someone at MT provides me with instructions on how to obtain the information you are looking for so I can forward it to you when the disconnects are happening. When you guys are looking at the AP/Clients it is in the middle of the night here and little to no traffic is flowing so disconnects are minimal to non-existent.

The clients have solid connections with signals in the -60's and CCQ in the 90-100% range yet they are still disconnecting regularly, there is a problem with NV2 like it or not, there are too many end users with the exact same problems reported on these forums and to support. It is hard telling how many are out there with the same problems that aren't reporting them.

The latest ticket is Ticket#2011052366000116

I can only emphasys on the urgency that MT really should take this issue serious. If I can't use NV2 reliable I really don't know how to keep the competition with airmax away from my clients base. You loose a customer, I loose my business.....

WirelessRudy · Wed Jun 29, 2011 3:07 am

Can i ask was there any system mis-configuration(s) on your AP's found by Uldis?

Have you found one sector AP is more prone to disconnects than other sector AP's,

I have noticed with a simple PTP (NV2) onto just 1 AP (NV2) has no disconnects but have sectors + Ptp links on a mast then some but all (AP's + Ptp) will have disconnects,

Also are you sure with unlicensed frequencies (i assume you are using) that signal interference on the is not somehow causing the disconnects,

Imho this has not so much to do with misconfigurations. I have 230 clients all similar configured (apart from name and IP address) spread over over 12 AP networks. Disconnects happen on each of the networks although more on these networks wher adjacent AP's are closer in range or where adjacent working channels are closer by.
But NV2 should also help to battle interference issues and solve some other issues (´hidden node´ for instance). I only think the protocol is just not matured enough to withstand interference data signals from other tdma radios...

chadd · Wed Jun 29, 2011 6:55 am

Can i ask was there any system mis-configuration(s) on your AP's found by Uldis?

Have you found one sector AP is more prone to disconnects than other sector AP's,

I have noticed with a simple PTP (NV2) onto just 1 AP (NV2) has no disconnects but have sectors + Ptp links on a mast then some but all (AP's + Ptp) will have disconnects,

Also are you sure with unlicensed frequencies (i assume you are using) that signal interference on the is not somehow causing the disconnects,

I only have one PTP NV2 link up and running at this point and no there are no disconnects on it. I had 4 towers that I switched over to NV2 and all but two have now been switched back to Nstreme do to disconnects and the "ghost" disconnects where clients will stay associated but will stop passing IP traffic. The ghost disconnect problem didn't show up until the 5.4 release, though I did have these problems with earlier revisions when running 802.11.

As far as I know there were no mis-configurations the only suggestions Uldis made is that the AP I gave them access to was running the "unofficial" V5.4 that was send out because of the port flapping that 5.3 caused. Also that not all clients associated to the AP were running 5.4 some were on 5.2 still, the funny thing is that the 5.2 clients weren't having disconnect problems.

It is possible that there is interference but at the same time there are clients literally 200 feet from each other and one will have a disconnect issue and the other won't. As I mentioned signals and CCQ are good on these clients and all of them are capable of moving the same amount of data. I have a mixture of Router boards from 112 to 433 and a mixture of wireless cards including MT brand cards and there is no rhyme or reason to why some are disconnecting and others aren't

Mplsguy · Wed Jun 29, 2011 9:42 am

Would this now mean that if I set my client to NV2 only this message dissapears and at the same time the scanning process for the protocols is skipped and client has an even faster change to connect to NV2 AP? (After all, AP is both with SSID and mac in the ´connect-to´ list, freq. scans is set for the AP freq. only so client is basically forced to listen to this specific AP only. If it still can't connect, other reasons for the disconnections come in place...., the onces explained later in this post?)

If you will set your client to NV2 only, you will get rid of messages that are a result of nstreme and 802.11 evaluating scan results. But this will not improve the speed at which client connects to AP. See, client at first scans frequencies in scan lists, records all APs it sees (nv2, nstreme or 802.11), and only then evaluates results taking into account your configuration (wireless-protocol, connect-list and other). The time it takes to evaluate scan results is negligible, so there will be no significant performance gain from using fixed wireless-protocol. If client does not have AP in scan results, it indeed will not be able to connect.

When I have client set to ´listen´ on AP freq. only, and connect to AP's mac or SSID only (and off course def. auth is off) this would mean the client actually doesn't hear any signal of that AP?

In general this is correct, but to be exactly precise this means that client does not receive valid "beacon" frame from AP (which is actually used to understand that the sender is indeed AP). If for some reason only beacon frames do not make it through, client will behave as if it does not "see" the AP (it will not be in scan results).

Ok, apart from the config changes/reboot/reset etc reason, what can be done to make sure these timeslots are better used and understood by client? All my networks are under 10km ranges, most even less than 500mtrs. Maybe NV2 is not really designed for such short distances?

There should be no distance limitations for NV2. You can not affect how clients are using their timeslots directly, apart of ensuring that data transmission between AP and client is best possible. If this problem is caused by hardware or software, it must be addressed by developer.

But does it have any priority? We are basically offering you guys help to sort it to out to speed it up. But we need feed back. We are beeing used as beta testers anyway, give us a bit more feedback and we all benefit! This post is a good start....

It does have some priority, but I can not comment on that.

Can it be concluded that most of disconnect problems are seen in PtMP networks?

chadd · Wed Jun 29, 2011 10:24 am

Can it be concluded that most of disconnect problems are seen in PtMP networks?

I can't speak for everyone but for me yes.

n21roadie · Wed Jun 29, 2011 2:35 pm

Can it be concluded that most of disconnect problems are seen in PtMP networks?
I can't speak for everyone but for me yes.

For me it has happened on both AP's + PtP links, temp solution with sector AP's was to use different wireless protocols on each AP (NV2 or 802.11), on the Ptp to use a higher gain antenna (not sure if the narrower TX/RX beam with higher attenuation beyond the beam, rejected better the other AP's or the Ptp's on the mast or if the narrower beam attenuated interference between Ptp point A to point B.

WirelessRudy · Wed Jun 29, 2011 2:39 pm

Can it be concluded that most of disconnect problems are seen in PtMP networks?

I am tempted to say "yes".
But, although I have some 8 PtP backhauls using NV2 which in general have no disconnects I have one that occasionally disconnects. Since on the PtMP the problem only exist on roughly 5% of the clients, and we would put this 5% towards these 8 backhauls... that would mean statistically I have 0,4 of my backhauls with the issue. Since that is not possible, and I have 1 backhaul at times disconnecting, you also might conclude the issue is happening on PtP as well...

But, since tdma timeslots in backhauls are only issued for one unit only (with the extra slot for possible new unit. Would this also be the case if AP is in "bridge" mode only, so not in "ap-bridge"?) not so much can go wrong here. If station would mis it, or AP would miss the beacon fm the station, next cycle will pick it up again, which is inmediately after...

So, my "yes" could actually also be a "no"?

WirelessRudy · Wed Jun 29, 2011 2:44 pm

For me it has happened on both AP's + PtP links, temp solution with sector AP's was to use different wireless protocols on each AP (NV2 or 802.11), on the Ptp to use a higher gain antenna (not sure if the narrower TX/RX beam with higher attenuation beyond the beam, rejected better the other AP's or the Ptp's on the mast or if the narrower beam attenuated interference between Ptp point A to point B.

Well, in here lies another finger pointing...
My backhauls usually use higher gain antenna's than actually needed to bridge the distance. I have done this on purpose, the narrower the signal beam and more focussed the recieving antenna, the better restistance against foreign signals. I'd like it when I actually have to lower the transmit gain on radio's to bring links in -50 to -65 range....
But this methode works for any protocol....

n21roadie · Wed Jun 29, 2011 7:00 pm

For me it has happened on both AP's + PtP links, temp solution with sector AP's was to use different wireless protocols on each AP (NV2 or 802.11), on the Ptp to use a higher gain antenna (not sure if the narrower TX/RX beam with higher attenuation beyond the beam, rejected better the other AP's or the Ptp's on the mast or if the narrower beam attenuated interference between Ptp point A to point B.
Well, in here lies another finger pointing...
My backhauls usually use higher gain antenna's than actually needed to bridge the distance. I have done this on purpose, the narrower the signal beam and more focussed the recieving antenna, the better restistance against foreign signals. I'd like it when I actually have to lower the transmit gain on radio's to bring links in -50 to -65 range....
But this methode works for any protocol....

Like i said is the source of possible interference at location or between point A to B or both, I cannot simply power down down active links + Ap's for a few hours to check this?

Ciambot · Thu Jun 30, 2011 1:20 am

Wireless disconnections occur both ptp, ptmp, when there is a noisy environment.
It is difficult use nv2 in tower with many radio link or in a single enclousure with 3 or more radio modules.
It is a serius problem: i need bandwith and stability. I hope MT fix this heavy issue soon.

chadd · Thu Jun 30, 2011 8:33 am

Like i said is the source of possible interference at location or between point A to B or both, I cannot simply power down down active links + Ap's for a few hours to check this?

Interference is an unavoidable part of our industry and if a protocol can't deal with it then it is worthless.

n21roadie · Thu Jun 30, 2011 11:41 am

Like i said is the source of possible interference at location or between point A to B or both, I cannot simply power down down active links + Ap's for a few hours to check this?

Interference is an unavoidable part of our industry and if a protocol can't deal with it then it is worthless.

Like i mentioned already from reading info about NV2 it states this protocol treats all other signals as noise, then this should be a advantage not a disadvantage?

WirelessRudy · Thu Jun 30, 2011 4:03 pm

Interference is an unavoidable part of our industry and if a protocol can't deal with it then it is worthless.

This is the best statement seen in this topic for a long time!

Hope MT embraces the issue and make it work 100% soon or we might as well see NV2 as a missed station. And who wants to be on a train missing stations.....?

Wireless NV2 messages explanation please!!!

Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Re: Wireless NV2 messages explanation please!!!

Who is online