Atheros issues..

wisp-equipment · Sun Aug 14, 2005 1:52 am

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.

Judd

OrCAD · Sun Aug 14, 2005 3:16 am

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

wisp-equipment · Sun Aug 14, 2005 7:40 am

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

billr · Sun Aug 14, 2005 10:21 am

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.

yogi · Mon Aug 15, 2005 2:40 am

{
: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 :D

tully · Mon Aug 15, 2005 10:56 am

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

billr · Mon Aug 15, 2005 11:24 am

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.

Eugene · Mon Aug 15, 2005 12:22 pm

support@mikrotik.com

wisp-equipment · Mon Aug 15, 2005 1:03 pm

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

Mon Aug 15, 2005 1:09 pm

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/in ... 6869443144

wisp-equipment · Mon Aug 15, 2005 1:09 pm

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

ela002 · Mon Aug 15, 2005 7:13 pm

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.

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

ela002 · Mon Aug 15, 2005 9:40 pm

I downgraded to rc9 and the problem is still there

I hope for a fix asap.

billr · Mon Aug 15, 2005 10:29 pm

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.

ela002 · Mon Aug 15, 2005 11:01 pm

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.

billr · Mon Aug 15, 2005 11:16 pm

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)!

ela002 · Tue Aug 16, 2005 2:04 am

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.

BullWeivel · Wed Aug 17, 2005 9:01 am

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.

billr · Wed Aug 17, 2005 10:06 am

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

Two totally different systems, the SAME problem..

Cheers..

Wed Aug 17, 2005 10:13 am

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

hitek146 · Wed Aug 17, 2005 11:35 am

I am having this problem also, and it seems like it happened around the time of rc7 or so... This happens quite often between our longer backhauls, so it seems like it may be due to noise. Sometimes it can happen 3 to 5 times in a 20 minute period, other times it only happens every few hours. What's really strange, however, that it only happens for brief periods, and then the link is back up, with the same signal it had before, which is a steady 75dB or 80dB(CCQ about 30 or so), depending on the particular link. What I did notice, though, is that the log on the AP end only shows the reconnection, sometimes many in a row, but not the disconnection. The log on the client shows both the disconnects and reconnects....

Hitek

billr · Wed Aug 17, 2005 12:10 pm

I see these disconnects on a TEST link of 50 metres length between 2 CM9s !!

The signal is -50 or better !! On 5.8 GHz and I am in the rural countryside so there is no question of interferance..

hitek146 · Wed Aug 17, 2005 6:57 pm

It does happen on our shorter, stronger(55-60dB) links, also, just not nearly as often....

jarosoup · Wed Aug 17, 2005 7:43 pm

billr, hitek,

Are these links you speak of set to a certain trasmit rate or are they allowed to use any rate that they see fit? If it is noise, and you do have set transmit rates (for example, 36Mb amd 6Mb only) perhaps this is confusing the radio and causing a dropout if it can't function at 36Mb for a short period of time? This of course doesn't explain why shorter test links do this as well...I'm still convinced that there are some issues with transmit rate settings and 5212/5213 cards.

ela002 · Wed Aug 17, 2005 9:03 pm

If there is a difference 20+ db between signal and noise level you can't have disconnects. There are some bugs with the drivers or something on mikrotik

Thu Aug 18, 2005 8:56 am

has anyone actually sent some supout.rif files to support? i don't see any coming from rc10

billr · Thu Aug 18, 2005 9:39 am

These dropouts occurs on:

Test 50 metre link set to 54 MBits/s. Signal level -50 dBm or better - ie S/N at least 40 dB !!!!

Real 1 mile link (signal -72 to -78 dBm) allowed to vary rate.

supout.rif files sent for both rc 2.9 and rc 2.10
Hope this helps you to fix it.

Cheers.

hitek146 · Thu Aug 18, 2005 10:32 am

has anyone actually sent some supout.rif files to support? i don't see any coming from rc10

You can probably see this in many of the supout files I have sent in the last few weeks, even those that were sent to you for other reasons, because it does happen frequently.... If I am not mistaken, I have also sent one for this specific problem. Just in case I have not, I will send a supout as soon as I can capture one directly after the problem happens. If there is anything else I can do to help troubleshoot this problem, please let me(and everyone else) know what I(or all of us) could do....

Thanks

Hitek

Thu Aug 18, 2005 10:43 am

everyone that has serious problems with RC10, please do the following:

1. wait until the problem can be seen (disconnections, errors, anything).
2. immediately make a supout.rif file
3. write a description of what you did and what happened. attach the supout.rif and send to support@mikrotik.com

you should remember this, it is very important that we can fix something. right now we do not have any open tickets with these kind of problems, and no rc10 supout.rif files.

billr · Thu Aug 18, 2005 10:55 am

You should have an RC 10 supout file from me @frambroadband.com

I am not sure however if this extends back in time long enough to show a disconnect.

Regards again!

billr · Thu Aug 18, 2005 11:04 am

I have just sent **another** supout file for RC 10 showing a link dropout ('no beacons received') about 20 minutes ago.

Sorry I was not quick enough to catch this sooner.

Regards, Bill.

hitek146 · Thu Aug 18, 2005 11:17 am

After a little more experimentation, this does seem to be a noise related issue. It would be more easy to troubleshoot on our end, however, if we had a noise level reading. The noise level is immediately available in the linux Atheros drivers, so why can't we see the readings in MT? It would help us greatly....

Hitek

PS- Now that I think about it, there aren't really many(any?) "error" boxes in Winbox, as can be seen in the Wireless Stats dialog. Are we being "sheltered" from immediate error readings in MT?

billr · Thu Aug 18, 2005 11:25 am

Hitek, I can't see how it is noise related..
One link that drops and reconnects is (as I said) a 50 metre or less link, for test and assessment - with -50 dBm or better signal and hence S/N will be at least 40 dB and probably nearer 50 dB.

And it is a) on the less used 5.8 GHz band and b) in a very rural area of the UK (East Anglia) - so the ambient noise is ALSO low..

Additionally, I am an active radio amateur - and I have always found the noise on ALL amateur bands very low, and my location - where I have the test link - particularly good as regards low noise..

Cheers !! (G0VDE)

hitek146 · Thu Aug 18, 2005 11:30 am

I agree that the problem is not strictly related to noise, but it does get worse when noise is introduced, as can be expected. I do have the same problem, although less frequent, on our links that are way out of interference range, over stretches of land that have nothing on them.....

Hitek

Thu Aug 18, 2005 12:49 pm

thank you all for the files, we are currently working on a solution

billr · Thu Aug 18, 2005 2:42 pm

For the record - working very hard !!

Thanks MT guys..

Regards, Bill.

budi_a · Thu Oct 27, 2005 5:55 pm

For the record - working very hard !!

Thanks MT guys..

Regards, Bill.

Dear All, all this atheros disconnection problem,
especially in WDS mode, have been resolved
in MT 2.9.6 ?

Thank you very much
//Budi

Atheros issues..

Atheros issues..

PRISM cards and rc10