Atheros issues..

RouterOS General
1

It seems we have a few links that tend to drop off after a few hours or sometimes a few minutes.

These links have been up for months, but occationally experience an outage, even though on the 8 Mile PTP with 29dBi solids on each side, we’re getting about a -60 signal on each end.

What happens, is the 5Ghz link tends to just stop working. The AP still shows an assocation, but the remote side is not pingable.

We can get into the remote via another network connection and it shows that its no longer associated to the AP.

This is happening while operating Atheros CM9’s in 5Ghz, or 5Ghz-Turbo, with MT 2.9rc9 (and earlier versions), with and without Nstreme.

With the latest 2.9rc10 and optimizations, we’ve been achieving speeds of 60Mbps sustained TCP throughput, but this problem seems to crop up still.

To fix the problem, we simply apply changes to the 5Ghz AP side, usually changing channels in the process, then changing channels back to normal again.

We’ve also seen this issue on 2.9rc9 with 2.4Ghz AP’s. It seems to be intermittant, random and again, a simple change of channels with an apply settings, seems to bring things back up.

I’m thinking about writting a script to monitor status and restart the interface, but I’d rather that the problem is fixed. :slight_smile:

Judd

2

Hi,
I’ve same problem and I try to explain in wireless section post.
I think is a bad SR5 management of the latest wireless package
CM9 work without problem.
regards

3

We are using CM9’s only. We have no SR5’s deployed.

We are still having this issue, so its not strictly related to the SR5.

Judd

4

As I posted in the compression thread, I also see this random link drop - sometimes after minutes, sometimes after hours. CM9s.

The only difference I see is the links usually reconnect after a minute or so with no intervention. Sometimes quicker. Nstreme and 5.8 G turbo.
Note this is in a very RF quiet rural environment.

Cheers.

5 
{
:if ([/interface wireless find name=xx disabled=no running=no ] != "") do={
    /interface wireless disable xx
    :delay 5s
    /interface wireless enable xx
    /tool e-mail send to="x@x.com" subject=([/system clock get time] . " x just $%^& out ")
    }
}

Would also prefer a fix. Replace the xx with the interface name and the $%^& with whatever expression you prefer :smiley:

6

Please send a supout file when you notice one of these clients that ‘should’ keep a connection, but is being lost. We can send you a script that will automatically make a supout just after this happens and email a notification to you.

We would like to see what reports the radio is giving. Also, it would help to see what the client end is doing – does it think it is still connected, or is it scanning for a new AP…

John

7

I am just the radio guy for our outfit - silly question, but where would you like a file sent please?

When the links are running they are FAST - I am not sure if the client is scanning, because the drop and reconnection is over a maybe 5 second period in our case, but presumably (I am fairly new to MT) the supout file would give you this info.

Regards.

8

support@mikrotik.com

9

FYI, we may have isolated one of these units that was losing link (about 50-60 customers associated to a 2.4Ghz AP, 6 radios in an ITX box with an RB18).

Troubleshooting today, I moved customers to another sector after we found that none of the tx power settings would work right on this specific radio, none of the channels would work right either (sometimes a channel would work, sometimes not, but we almost always ended up back on 2442 or 2447, after juggling until we saw assocations come back). Sometimes it required juggling channels, sometimes it required juggling tx power, until we saw assocaitions return.

We disabled that sector now and this morning, I have someone going out to swap out the radio and amplifier. I’m fairly certain that its a bad radio or amp. We’re leaning towards amp, since we think this amp came off a bad Cisco AP only two weeks earlier at the same site that was having similar problems (Cisco began locking up).

Anyway, I should know later today if the amp/radio combo was a problem. We’ll test the radio later, but these customers have been having a heck of a time lately.

We are seeing some similar issues with a radio right next to it, with an amp. Another radio next to it without an amp, isn’t having that problem. But, we also had a few other issues, so we’re trying to clean things up so we can get better documentation of the problem.

There is a possibility that the sector could be a problem as well. Wet or bad connector/pigtail (Maxrad sector). I think we’re swapping the antenna as well, so we’ll have all new gear in place of what we had problems with. If the problem persists, then it “might” be software. But I’m leaning towards a hardware problem at this point.

The other 5Ghz link, is still up without a link loss like we saw before. I recently upgraded it to 2.9rc10 with the normal wireless package (non-legacy) and its looking good.

Judd

10

remember that for the tx-power setting (and some others) to work, you have to set frequency-mode to manual-tx-power.

http://www.mikrotik.com/docs/ros/2.9/interface/wireless||0.09768366869443144

11

Followup on this last post..

With the problem radio, we have noticed that in an AP scan, a nearby competitor AP is about 1/2 to 1 mile away and is showing up with a -58 to -60dBm signal strength at our AP on this sector that was having problems.

I was almost certain it was a noise problem, because customers only have link strengths of about -61 to -85 and if the noise gets bad during traffic from the competitor, then those customers would end up with a negative SNR. While idle, we’re ok, but during peak periods (which is when we have problems), we’d see problems, usually only on that sector (about 150 customers on that ITX board and about 1/3rd are on that sector).

We also disabled all other 2.4Ghz radios while troubleshooting, to verify that we weren’t causing self-interference, but that didn’t make even a little difference, the link quality on the trouble radio/amp/sector was still bad and not even getting associations unless just the right combination of tx power and channel were set.

So, I’m still thinking bad radio/amp, but it could be noise related as well.

Judd

12

Same problem with atheros cm9 using it in station mode. Problems started with rc10. Random disconnects:


19:03:26 wireless,info wlan1: lost connection to xxxxxx, no
beacons

19:03:26 wireless,debug wlan1: STA starts scanning
19:03:27 wireless,debug wlan1: STA scan over, results:
1
19:03:27 wireless,debug wlan1: must select network
19:03:27 wireless,debug wlan1: no network that satisfies connect-list, by
default choose with strongest signal
19:03:27 wireless,debug wlan1: selected xxxxxx, SSID xxxxx on 2437
19:03:29 wireless,info wlan1: connected to xxxxx on 2437, SSID
xxxxxx

13

I downgraded to rc9 and the problem is still there :frowning: I hope for a fix asap.

14

ela002, what you posted is what you see in the log??

I am seeing:

10:57:44 wireless info wlan3: disconnected 00:11:22:33:44:55, extensive data loss
10:57:49 wireless info wlan3: 00:11:22:33:44:55 connected

And sometimes:
10:57:44 wireless info wlan3: disconnected 00:11:22:33:44:55, reassociating

But not this afternoon.. It has been quite stable.

15

Yes it’s from the log file.

The error that you are seeing happened to me with Prism senao. Also try to set preamble to ‘long’, not both.

16

You know, I was wondering about preamble with CM9.

Currently it is set to ‘short’… the (probably wrong) logic being, less management traffic.. (but I have probably totally misunderstood what preamble does…)

To confirm, the error I have is with CM9. I have a Senao on the system but it is not doing anything at the moment - it is a spare..

Would appreciate knowing about preamble (yes I probably should not have to ask the question)!

17

From the docs

preamble-mode (both | long | short; default: both) - sets the synchronization field in a wireless packet

long - has a long synchronization field in a wireless packet (128 bits). Is compatible with 802.11 standard

short - has a short synchronization field in a wireless packet (56 bits). Is not compatible with 802.11 standard. With short preamble mode it is possible to get slightly higher data rates

both - supports both - short and long preamble.

18

I was seeing this crap in my rb500: (using prism card)

10:57:44 wireless info wlan3: disconnected 00:11:22:33:44:55, extensive data loss
10:57:49 wireless info wlan3: 00:11:22:33:44:55 connected


Just like the other person had been getting.

Setting this to LONG only fixed it.

Okay this is a BUG MT. It should be smart enough to figure it out.

19

As I said, I see exactly the same on a CM9 on a PC-pased system !!

Two totally different systems, the SAME problem..

Cheers..

20

this kind of error usually appears in two cases - when the signal is not good or when the other end didn’t succeed in wds connection (happens with some 3rd party devices that do not understand Mikrotik’s WDS).

In 2.9 there are simply more informations in the LOG, are you sure that apart from the log entries, you also have some real problems?

If so, make supout.rif files and send them to support. make sure you are useing latest 2.9