Wireless NV2 messages explanation please!!!

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”
    :sunglasses: “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! :wink:

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! :frowning:

And to add to the “NV2” issue:

I have units with ´ghost´ disconnects (see http://forum.mikrotik.com/t/ghost-disconnects/48102/1)
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… :frowning:

No reply???

Does this mean everybody knows? Or nobody knows?

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/t/5-0rc9-lost-connection-medium-access-timeout/44770/1

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.

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 :confused:

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?

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…?

@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?

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! :astonished: :astonished:

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”?

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

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 have a question has MT ruled out configuration issues as the cause of these NV2 issues?

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.

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,

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… :frowning: :frowning:

Finally some movement on this issue! :smiley:

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 - ..> :smiley:> 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…

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…

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…