MikroTik

I have a strange problem occuring at two of our tower sites with the same configuration on both:

RB532A - (running Mikrotik RouterOs 2.9.42)
SR2 (distribution network)
SR5 (backhaul)
48v POE
250ft cable run

Site 1 has been up for a little over a year with no problems until recently, the issue is when the system gets rebooted. After a reboot only about 1 to 3 of the CPE's will re-associate. If I go disable the card and re-enable it, I may get 1-3 different or some of the same CPE's to reconnect. I have to proceed to disable/enable the card over and over from 70-150 times until finaly all of the CPE's will all associate then everything works like normal.

Site 2 is a replacement unit for an existing system that was in place that I am replacing with the setup from above. As soon as I replaced the old unit with this new one and booted up the new one, I get the exact same issue as Site 1 where I have to disable/enable the card until it finally associates everyone.

I noticed a few threads on the forum about people having to disable/enable their wireless interfaces to get everyone re-associated but I haven't seen a resolution. I left a message for Ubiquiti to call me back and also emailed them so we will see where that gets us.

Anyone have any idea's what might be going on here?

What kind of client ? How many clients per antenna?

Mixture of Tranzeo CPE-200 and CPQ's. If I log into the CPE via local ethernet, it sometimes shows the AP in the AP list and sometimes it doesn't during the process of trying to get the devices connected. When it shows up, I can click on it to tell it to connect but it still won't associate. But once I do the disable/enable trick long enough, it will connect and then I can reboot the CPE as much as I want and it will reconnect everytime.

I received a response back from Ubiquiti stating they have not heard of any issues like this related to the SR2. I guess I need to try swapping the cards out with a CM9 or R52. Any other suggestions?

If all else fails try a Prism 2511. How many clients are on each card?

20-30 CPE's connected at each site.

I am thinking about swapping the cards with a Senao/Engenius NMP-8602 400mw so I won't lose the power I had with the SR2.

Let us know how it works out with the 8602.

I too have observed the same problem.

I am running an RB532, with an SR2. The backhaul is the Ether1, connected directly to the network switch in the equipment shelter.

When I do something to promp the A.P. to ask the clients to re-register, they usually don't unless I toggle something else, like the bridge, etc.

Sometimes when in the fugue state, I only see one to three clients registering. Why does this happen? MikroTik support can't seem to figure out what I am talking about here.

Adam

I assume you are using POE? If so, are you running 48v? I wonder if it is power related, I have thought about switching out the power supplies to see if that makes a difference.

I run mine from a 15 VDC power supply.

Mine is simple, a RB532 operating in a simple bridge mode with one SR2 on the RB532 board.

Any ideas?

Adam

I replaced the unit at one of my sites with the same setup except I used an XR2 instead of SR2 and I am still having the same assocation issue, i have to change frequencies and enable/disable the card until the CPE's finally start associating. I am beginning to wonder if it is related to the CPE. I am using Tranzeo TR-CPE200s. The only other thing I could think of would be my wireless config which I will post below.

/ interface wireless
set wlan1 name="wlan1" mtu=1500 mac-address=00:15:6D:63:14:6E arp=enabled disable-running-check=no radio-name="00156D63146E" \
mode=ap-bridge ssid="ap4" area="" frequency-mode=manual-txpower country=no_country_set antenna-gain=0 frequency=2417 \
band=2.4ghz-b scan-list=default rate-set=default supported-rates-b=1Mbps,2Mbps,5.5Mbps,11Mbps \
supported-rates-a/g=6Mbps,9Mbps,12Mbps,18Mbps,24Mbps,36Mbps,48Mbps,54Mbps basic-rates-b=1Mbps basic-rates-a/g=6Mbps \
max-station-count=2007 ack-timeout=dynamic tx-power-mode=default noise-floor-threshold=default periodic-calibration=default \
periodic-calibration-interval=60 burst-time=disabled dfs-mode=none antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none \
wds-default-cost=100 wds-cost-range=50-150 wds-ignore-ssid=no update-stats-interval=disabled default-authentication=yes \
default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0 proprietary-extensions=post-2.9.25 hide-ssid=no \
security-profile=default disconnect-timeout=3s on-fail-retry-time=100ms preamble-mode=both compression=no allow-sharedkey=no \
comment="" disabled=no

How many Tranzeo CPE-200's and CPQ's do you have at each site?
I seem to remember a lot of people having problem's with Prizm clients connecting to Atheros AP's when they first came out. Maybe this is just the same old problem.
One way to know for sure is to put a prizm card in the AP. Or you could move all the CPQ's to one AP and all the 200's to the other and put in a Prizm card in the AP for the prizm clients and a Atheros card for the Atheros clients.

Anyway, I have always found it's better to keep the chipset as close as possible on the AP's and clients.

I too am having this problem. Using routerboard 532 and SR2. Setup as AP Bridge. Have to disable and enable. CPEs are a mix of CB3s, Smartbridges and Zinwell boards. I did notice that if you let it sit for a while groups of the CPEs will associate. Like 5 first then 10 more 15 minutes later. Diffferent groups associate at different times, but the qroups aren't the same everytime.

Yeah, but in the mean time, the phone starts to ring, and then people are offline.

When it works good, everyone pops in almost immediately.

Why is this? Doesn't Mike at Ubiquity surf these forums? Maybe he can shed some light on the subject...

Adam

Worked on it some more last night while everbody was hopefully sleeping. Tried every different config on the AP with no luck. Sometimes most of the CPEs asscociated and other time 1 or 2. There is about 25 total.

Sometimes when I made a change to the wireless card like channel, the card doesn't even start running. I had to enable/disable the card to get it running again.

I did notice that the CPEs seemed to associate better when the SSID wasn't hidden. Maybe just a coincidence though.

I have another exact setup that does the same thing but not as bad. I make a change to it, then disable/enable card and all CPEs come back. It has more clients than the other one.

Yeah- now.... Why does this happen? Are we the only ones to see this? Can't be....

Adam

I just posted this below on another thread, these threads should be joined, as they pertain to the same things.

http://forum.mikrotik.com/viewtopic.php?t=15894


I am starting to see a pattern, I first posted this http://forum.mikrotik.com/viewtopic.php?t=15434 and thought it was a single user to start, then I figured it was mixing the Atheros chipset and the prism.. Now I am see it even more clearly

Basically I am seeing the problem spread over my 27 node network like a disease. It happened on my most popular nodes first, and then has been affecting the other nodes as well, and the same fix works on all node.
to fix you do one of 2 things
1. disable...enable.. a 1000 times till you see everyone get on.
2. stick in a prism chip set, everyone connects but then they complain about speed and other things, things that are solved by switching to the atheros.

Now I have a theory, I believe it is the RB113 board out there. When I get a call that no one can connect on a node that has not had the problem, I notice that there has been an 133 user added. the node in question was working perfectly with 32 people on it, now 2we added 2 133 mikrotik clients, and BAM, that node is now having the same problem.

I am in the process of adding a new card to the AP, and moving all the atheros cards to it, I have done that to 1 node, and as soon as I moved the RB133 clients to the new card, everything went back to normal

I need people to chime in here and let us know if you have this problem, and if you are using RB133s in the field.

NOTE: I love the RB133 as a client, I have solved many issues by having the ability to login to peoples' CPEs and do diagnostics, now if we could beat this latest issue we will be in Mikrotik Heaven.

Funny you suggest that; I am about to roll out my first Rb133C client on Monday.

All of my clients are Engenius radios presently.

When you program your RB133C, do you do this via the serial cable, or by using the Winbox? When I set-up my Rb133C units to talk via serial cable, the computer freezes and the Rb133 seems to stop responding.

Don't have that problem when talking to the RB 532, though. Not sure why it is prevelant to the RB133C.

Adam

I use winbox and connect via the MAC address to configure. I wonder if this problem is occurring from bug in the OS.. what versions are people running? All my problem nodes are 2.9.38 or newer.

I use 2.9.43 at the A.P.

I need to get the RB133 running for Monday's install. It should be the first one I have out in the field for the clients. - Wish me luck!!

I will connect to it using WinBox and see how it goes. I am trying to get some more compatibility out of the system, and I think that if I use the RB532 and RB133C, this would be best.

Adam

ok, is anyone else seeing this issue? Please speak up if you are.. this is getting worse and worse. Last week it was on 2 nodes. this week, it is now affecting 5 nodes.

I have it on every one of my RB532 boards. Makes me VERY wary of making any changes to anything, for fear of dumping everyone off and having them not come back.

Why does this happen??

Adam

Obviously there is a problem either within mikrotik or the cards. I am wondering why someone from mikrotik hasn't chimed in yet to let us know which one it is. At least let us know which cards do work fine with this configuration.

This is what I was going to upgrade all of my APs to and use for all of my new installs, but am going to start testing other hardware now.

When I had sent this complaint to Serjegs, with the corresponding Supout file, AND the log, Serjegs told me that I needed to get better clients; suggesting the Rb133C.

Come on MikroTik.... There are more people with this problem than I. We need some support from either M.T. or Ubiquity Networks.

Keep in mind that I have the same problem with the R52, SO: this makes me consider that we have a RouterOS issue.

But, then again, I am a noob after converting to MikroTik from BriLan.

Adam

Better CPE? I thought their 133 boards were having the same problem. From what I have heard it happens with just about every chipset out there for CPEs.

Maybe we need to find better APs? Haven't had this type of problem with any of the other APs I have had.

I've got 2 RB133c as a ptp bridge.

2 rb133c ROS 2.9.38
2 SR9
2 13dBi Pacwireless yagi
Laptop AC as the 18v Wisp-router recommended wasn't enough.

Every time I make the slightest change to the AP, try to find a clearer channel, etc, the CPE (of course, at my home) refuses to reassociate.

I have to change the AP back to previous config, change the client, then change the AP, then reboot the AP. This is a pain in the @#$@#$. I have a thread about it, not a response that I've seen. Its somewhere along the bottom of the page.

If I remotely change the AP without power cycle, the CPE will not reassociate. Even with watchdog. Apparently, a soft reboot won't do the job. I can see the AP sometimes, but cannot associate.

I have to change the AP back to previous config, change the client, then change the AP, then reboot the AP. This is a pain in the @#$@#$.

Next time this happens just try to disable - enable the card over and over till everyone connects , if that works, then you are in the same boat as the rest of us.
What I do is do a MAC ping on one of the 133 clients, the I start re-enabling the card, I can tell when it works cause the ping times on the 133 goto 2.. if it doesn't work, then they ping with 80%packet loss and 500ms+ ping times.

I wonder if the reason MK doesn't see it in testing, is they don't have a big enough test set up, I have at least 20 people on the least crowed card that is having this problem.

This is exactly what I am seeing too.

I am about to roll out one of the RB133Cs in the field on Monday. I hope this doesn't make the situation any worse.

In the mean time, I wish that someone from MikroTik would help us address this. I do concur, the problem happens when the A.P. sees more than fifteen clients.

One or two, no problem at all.

Adam

Is there anyone having this problem with a NL-2511MP in the AP and all prizm CPE's?
I think if you have all Atheros (AP and CPE) or all Prizm you don't have this problem.
Maybe somethimes things work fine untill you hit that magic number of clients and then things go nuts.

My network is made up of 70% CB3, 5% Deliberant, and 5% Tranzeo. I never had any problem till I started adding RB133 with R52 cards in them. I dont have the problem on nodes where there are no mikrotik CPEs, I dont have this problem if I user Prism chipsets in the APs, but when I do that I get all sort of complaints, the prism cards are just not good enough in crowed environment.

I have an old routerboard don't remember the model number, running prism and never have a problem using Mikrotik 2.8.21. Have a mix of tranzeo, CB3s, zinwell, and Smartbridges for CPEs. Been up for over 2 years without a problem.

The only reason I upgrade to Atheros cards is when I start getting a lot complaints, With Prism you cant see the noise, nor any CCQ readings. When I switch to atheros, I get both, and I am able to track down and fix these types of noise/CCQ issues. That has been working great for about 1 year.. then suddenly a few months ago this disconnect problem started happening, I replaced everything , Motherboard, wifo cards, pigtails, antenna,powers supplies, and nothing worked. then after looking at some other nodes, I noticed they were running prism cards. so I stuck in the prism card, and everyone connected. But that I had the old complaints of slow service at night, bla bla.. high ping times.. so I am damned if I do, and damned if I dont.

Hi guys ,

i have same problem with XR5 with 2.9.42 . When use winbox to control/config the AP , the system come instable. Deauth , variation of noise-floor ( from -100 to -115 ) .

RB532 with 2 miniPci ( 1 XR5 and 1 SR2 ) , but with problem only on XR5.

an suggestion's ?

Just to let everyone know I have seen the same problems and my clients were tranzeo and teletronics. I've had several people tell me not to mix client equipment or you will see problems ( prism or atheros) . Although you can use a tranzeo AP and not see these same issues, just high ping times and mad customers. I had tried the sr2 about a year ago but these issues weren't getting resovled. Then I got lucky and lightning struck it dead so I put another unit up with the 2511 card and all was well. Then about a month ago I tried to install a Tr-cpq on this tower and it won't connect to the prism card in the AP although ealrier firmware versions of the same unit would ( strange ). So within the last month I installed another rb532 with an xr2 to see how things go. Its still up in the air because this tower only had 12 clients but I have seen a small case of the connection issue. By this I mean I only need to disable and enable a few times and all is well. Sometimes never. I'm getting ready to deploy 3 more xr2's were I currently have a tr-4500 with about 60 clients and use pac-wireless omni sector on it so I will have more to report in about a week. I hope all this compatible equipment becomes compatible sooooooooooon!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Is there anyone having this problem with a NL-2511MP in the AP and all prizm CPE's?
I think if you have all Atheros (AP and CPE) or all Prizm you don't have this problem.
Maybe somethings things work fine untill you hit that magic number of clients and then things go nuts.

My link is ptp, rb133c and SR9 on both sides. About as simple as you can get.

Hi everyone

I've read through all the post's on this thread to see if I can find a common factor or more. I think I have the same kind of problem on my AP with an Atheros chipset, SR2. Someone mentioned it only occurs on AP with more than 15 clients on the interface, mine has 30, so with that I concur, because while most of my other AP's run on Prism 2511 where I have more than 15 and up to 30 clients or more with no problems whatsoever. I have other AP's running Atheros but with less than 15 clients at the moment where I have not seen the problem described.

Further I don't think it is Mikrotik OS related, because I had the same problem on a Wrapboard running 2.8.28 with the SR2 in, when the same problem started happening when my clients became more than 20 on the AP. I then replaced the setup with a RB532 and Mikrotik 2.9.23 and still the same problem exists. When something happens that causes all the clients to connect simultaneously again, like power failure or scan or setup changes etc, the AP struggles to connect all the clients again, and those that do, have slow traffic and high pings. It only happens on the interface AP with the many clients, the other atheros AP in the bridge with about 8 clients never has the problem.

It might still be a driver issue though for the Atheros cards which Mikrotik uses?

I think all of us with the problem should write down their configs like, hardware (wrap or RB's or other), software (Mikrotik version etc), Wireless card used in AP, bridge config or not, how many clients on AP, type of clients (mixed or not), wds or not, etc

Mine is:
RB532 with 2 SR2's in AP-bridge mode setup in a bridge
AP interface with the problem has 30 clients, mix of prism CB3 and mikrotik with atheros card clients
Mikrotik OS 2.9.23
no WDS

Best regards and hoping for a solution soon
Albie

I am seeing the problem on every A.P. that I use the R52 or SR2 on.

My A.P. configs are as follows:

24 clients:

RB532
SR2
Router OS 2.9.43

25 clients PLUS WDS:

RB532
R52
Router OS 2.9.43

And yes, I have the same problem on both of these units. It is both disturbing and annoying.

Adam

Is there anyone out there that is NOT having trouble with Atheros chipsets and prism clients? This problem is not going away, and needs some mikrotik attention.

I'm also having these issues, pretty much as everyone else has described them. Sometimes it helps to change the MAC address and B/G vs B only modes on the AP.

I run in B mode only on all my nodes, no G cpes in my network..

just fishing: try changing preamble-mode=long
sorry i don't have prism.

If you will go with an all atheros sytem, then i suggest the older 'classic 5213 cards'. its a case of Super-Het vs the newer DC ZIF single chip.

thanks for the suggestions, but I am having troubles with SR2 cards that read AR5213 in the winbox interface,perhaps that is wrong, but it is what I read. Also I just tried to change the pre-amble to long, and had the same issues, then I switched it to short.. not change.. set it back to both and the disabled-enabled about 50 times and got all back on..

next suggestion

My network is made up of 70% CB3, 5% Deliberant, and 5% Tranzeo. I never had any problem till I started adding RB133 with R52 cards in them. I dont have the problem on nodes where there are no mikrotik CPEs, I dont have this problem if I user Prism chipsets in the APs, but when I do that I get all sort of complaints, the prism cards are just not good enough in crowed environment.

R52, XR2/5 are 5414 single chip (DC with ZIF), lots of trade off, cheap to make and cost more with marketing hype.
SR2 is 5213 (uses two chips), a good card, but watch the power output. don't drown the clients.

How about proprietary-extensions=
After any changes try rebooting. (another fishing suggestion)

I talked with someone at ubiquiti today and he thinks the problem has something to do with noise. I don't have an sr2 or xr2 up with more than 10 clients on it to see if it helps but I think it would be worth a shot. I do have 1 up and running and for the heck of it I set the noise floor at -85 and all clients re-connected. Although there is only 10 clients on this radio and I have ran into this same issue before and would like to correct it as soon as possible so that I can deploy more locations. If someone could try these settings and let me know how it works out I would appreciate it.
Thanks and Good Luck
By the way ubiquiti is supposed to get back with me on Monday to work through this and when I have good news I will post it here.

Please do post what you find!!

I have been battling this thing across our network since implementation.

I can start to raise the minimum noise floor and see what happens... Can anyone verify this on an AP with more than twenty clients?

Adam

I have used the noise floor, and I have never seen it to a thing, I can set the noise floor to -70 and the same connecting problem exists, and people with -70 or worse still get right on.
The way I thought the noise floor worked, is that If I set it at -70 then everyone with a -71 or worse would not be bale to connect, is that the way it is suppose to work?

To the best of my knowledge, I thought that the minimum noise floor figure was a minimum threshold for connectivity; if the client was coming below the threshold, then they would not be served.

Alright... What is the next idea?

BY the way, I swapped out my SR2 for an R52 and am having the same problem.

Adam

I talked with someone at ubiquiti today and he thinks the problem has something to do with noise.

the noise floor on my nodes averages around -105, which is pretty good. If a -105 is considered noisy, then we have a major problem, or is it a wrong reading ?

Across my nodes, I see noise floors of -95 when they are by themselves, and -88 when the radios have pre-amps in front of them.

Adam

I use no amps.

I have some with amps, some without. In both cases, the problem persists.

Adam

Is there anyone that has the same setup but with an earlyer version OS like 2.8.X or maybe 2.9.26?
Could this be tested?

yeah, we need to get to the bottom of this one.

Adam

I join in guys.

Same Problems on 4 towers with SR2 and one doesn't even have 10 clients connecting to it. Seems to be related to the number of clients in the area. Remember all wifi radios go into idle when no traffic is going through, and so the tx power drops. It seems when the CPEs are in idle, with high interference from other units, their transmission is too weak to be picked up by the Tower! ie other active units can kill the signal of idle units. When we enable/disable, and if we are lucky and there is no transmission/interference at that instant, all the clients connect without any problems.

Yes, it must be a CPE problem, and we advise MT to devise a way to keep some traffic going through between the APs and the CPEs even if its only on physical level in order to keep the clients associated. Just run a continous IP scan, and pay attention, when after disable/enable a 1000 times and the clients connect, check the signals' strengths, they are good and then fade when the CPEs go into IDLE mode. We use PPPoE so there is always LCP to help.

One powerful CPE at close range, when it transmits, can kick out other further CPEs. The problem might also be lying in CSMA/CD. Try using channel 11 for better results., Works for me.

Some may argue that when a CPE picks up the tower, and still can't associate, that is proof the CPE is not in idle mode. Just check on any tower where you don't have problems, and you will notice that when the CPE first associates, the signal is idle until you ping or start sending data through it.

Keep in mind guys, that if you were operating at channel 1 and I had a backhaul at channel 12 firing through your omni with a high enough power, and you are not using a channel filter; I would saturate your amps and your links would drop.

You REALLY do need a spectral analyzer to diagnose this one.

That is my half cent

I posted on here earlier today and my post was deleted. Whats up?

I see the problem across ALL of my A.P. units, operating even in simple bridges.

For these simple bridges, the only RF in the air is the RF generated by the SR2, XR2, etc. The backhaul is a piece of Cat5E on the network switch.

This really makes me think that the problem is firmware or hardware related...

Adam

You REALLY do need a spectral analyzer to diagnose this one.

That is my half cent

This is not an option. Other APs work fine, mikrotiks should to.

I have a nice lab spectrum analyzer; I doubt dragging it out and setting it up would shed any light on this.

My gut feeling is that we have a firmware / software interaction issue, and it is terribly annoying and difficult to deal with.

Adam

We have the same problems with our Mikrotik 532 and Ubiquiti cards. We have mostly Tranzeo clients, with some diliberants. The tranzeo's range from original CPE-80 to CPQ's. We had mostly Tranzeo AP's, but the tr-6000 series like to stop responding often, especially with more than 10 clients. So we replaced a few with the 532's, it's a love/hate relationship. When all the clients connect, it's great, but if you have to make a change, you just never know if the clients will come back. We are getting ready to homogonize our network with 532's and Ubilquiti cards to simplify management and capability, allowing for better traffic control and routing. I will post configs and client counts later for existing AP's with issue.

I think that the issues are software related. When the clients can't reassociate you can look at the logs and see that the clients are being sent deathentication packets.

When I setup a wireless log named debug, and made the logging lines really long, I found that the clients were being sent Deauth packets, but not all twenty five of them.

The clients that were being sent the Deauth packets were the five or so that could register, but were toggling in and out.

Adam

I have set up a 2nd radio and antenna on one of my problems nodes. I am in the process of switching clients from CB3s to RB133 boards with r52 wifi cards in them, and then moving them to the 2nd antenna

so current setup in AP is

wlan1 sr2 with 32 clients consisting of tranzeo, CB3,and deliberants, having the association problem

wlan2 sr2 with 22 clients consisting of Atheros only.. a few tranzeos and the rest are RB133


wlan2 works fine every time
wlan1 has the association problem.

so if MK would stand up to the plate and tell us that prism and atheros don't mix.. then we can go about the painful process of deciding what to do.. but currently we all hope for a solution to this problem from MK, that does not involve scrapping 100s of prism CPEs.

I've been having this problem for a year now.
I finally solved it by hanging Deliberant AP's on my busy towers and forcing the Tranzeos and Zcomaxs on them and letting all the other clients connect via MT.
It IS a MT problem and needs to be fixed.

Something to do with ACK timeout and overwelmedby connections. Theory only.

Problem is that now you dont have the signal reporting and traffic reporting that you have with pure MT - kinda loose the MT effect.

In fact I'm sitting at the bottom of one of my towers right now turning the XR2 on and off so I can get the clients to connect.

What a pain in the ass - I like the comment from MT that we need to get quality CPE - same attitude when I posted earlier this year about this problem - He turned off my thread after saying I needed to upgrade my OS.
RRN

I'm wondering if anybody has tried using any of the 3.x beta and if it had an affect with this issue?

I've been having this problem for a year now.
I finally solved it by hanging Deliberant AP's on my busy towers and forcing the Tranzeos and Zcomaxs on them and letting all the other clients connect via MT.
It IS a MT problem and needs to be fixed.

We have a Deliberant AP up also, although it was put up to replace a tranzeo. I would agree this is a MT issue.

Problem is that now you dont have the signal reporting and traffic reporting that you have with pure MT - kinda loose the MT effect.

Don't Ikarus or Star OS offer this information, I haven't used, just read up on. Maybe that is a better solution, has anyone tried?

I have tried the Beta versions with disastrous results.

With the Beta running on my A.P., the thing would randomly drop everyone off, and force them to re-associate, which we all know they never did on their own.

And, of course, everyone got all mad....

Adam

ok, got it.

Thanks Adam, just haven't heard anybody had tried.

Again I ask! Is someone going to try one of the older Versions?
If this is a MT problem that just started then try a net install of an older ver. and if the problem goes away then you can start nagging MT some more.

I don't have any experimental A.P. units to test this on... But I could throw together a RB532 an a SR2 and look around the web for a package of software older than 2.9.38 if necessary.

Adam

My oldest version having the problem is 2.9.29

I am all 2.9.43 or 2.9.38 here.....

And, since I followed the advice of M.T. to upgrade to the latest version to see if it fixes the problem, I don't have anything to help out here on the shelf.

Adam

I am with you.. I use the MK approach.. upgrade to fix problems.. now if someone from MK wanted to me test a particular old version, I would have no problem, but just too say 'to try older versions' is a crap shoot.. and each time we do these things it takes the nodes down.. which makes people unhappy as well.
So again. I am willing to help, as long as there is a plan to help, and not just throwing the problem back at us.

I'm sorry if I sounded like I was throwing the hot potato back to you. I was simply trying to help find the problem. Is it the Atheros chips, MT software or something in the "other" category.
I had similar problems when I first added the Atheros AP's to my network and the universal answer I got was to use all atheros radios in my network. So, today thats all I have in my network and I don't have the problem. But then again I think I have the most upgraded network there is.

It all just sounds odd that these problems just started. Can anyone say when? Or what you changed to make this happen?
From some of the posts it looks like just adding a few atheros radios to a network with mostly prism radios did the trick.

Maybe I can setup all these CB3's and Deliberant's, connect them to the MT AP on my roof and see what happens. I have at least 30 CB3's if someone wants to could help set this up.

Hey everyone,

I got a PM from a different site that I frequent. I work on a few WISP's and am a WiFi instructor and CWNE. That doesn't mean I have all the answers, but have some experience.

Has anyone done a packet capture? I have found a number of problems with CPE's and AP's by analyzing the captures. If anyone can perform a capture with Omnipeek Personal (free) I would like to look at it. I live in Arkansas (not from there) so if anyone is having these problems within a days drive of Central Arkansas I would be happy to come take a look at it. My email address is gene@ my forum handle dot com.

Gene

I have stated previously that I have had the same problem on Mikrotik V2.8.28 on a Wrapboard as well. When this problem started, (my client base grew) I first thought it was the Wrapboard, so I changed to a RB532 and Mikrtoik V2.9.(various versions) and problem still exists.

Regards
Albie

I just got off the phone with one of the WISP owners on this board. He told me some more details and it is definitely a compatibility problem. I believe it is a problem in how the devices are handling association.

The next step is for me to look at a packet capture of association. If anyone has the Ubiquiti SWX-SRC card (with the external antenna connectors) I can walk someone through how to perform the capture. It really isn't that hard so let's do it!

Gene

I sent the IM, I thought we needed some fresh blood or at least someone out side our box that may be able to help out here.
If you can pin point the problem and come up with a solution you will be the hero of the month.

I would love to be the hero of the month. That packet capture is the place to start. If no one wants to set up for packet capture I can send them a laptop ready to go.

Gene

gthill what do I need to download to do the packet capture.
Thanks Brad

Hi Gene

Will your software read a "sniffer" packet capture file from Router OS as well? I know Wireshark can read such a file.

Best regards
Albie

Gene I looked back and seen where you listed omnipeek and I am currently dowloading it so I can get a capture for you.

Brad,

You must have a compatible card before Omnipeek will work. The Ubiquiti card I mentioned is a good one but there are others if you don't have it. The nice thing about the Ubiquiti is that it has external antenna connectors so you can point to the AP from your CPE and get both sides of the conversation at once.

Albie

It should read that file. Can you email it to me? gene@ my handle dot com.

Gene

all of us having this problem need to send an email reguarding this to get someone on the ball. Make sure you explain it well.

Thanks

I am actually quite interested to see that no other people from MikroTik have stepped in and posted something about the topic.

The problem exists with the R52 as well.

Adam

The original poster and I talked about this last night. He is going to send me a capture in the next few days. I'll keep everyone up to date.

Gene

I just noticed a correlation between the ACK and the atheros/prism association problem.

When the problem is occurring, on the AP.. look at your ACK value under status..

from the previous post it was stated
ack timeout is calculated on each association when ack-timeout=dynamic.
A little bit of packet loss can leave it at an unreasonable high ack-timeout, giving really poor performance.
ack-timeout=dynamic is meant to be used when you initially setup the link and should be fixed at the suggested ack-timeout

on a problem node I see the Ack value at 90.. on a working node I see the ack value at 53
after a few minutes of the card being enabled it finds the ACK it seems to stick on a number

when the problem of NO cpes can connect the Ack value is way high.. mine currently is setting at 349

after disabling and -re-enalbing the card a 1000 times.. the act value goes to a normal rate of around 50..

so is the problem related to the dynamic ack ? or is the ack a byproduct of the problem.

An ACK timeout is designed to change to accommodate long distance shots. If the ACK timeout is too low, the AP will not receive the ACK back in time because it takes longer for the ACK to come back, due to longer distances. If the AP doesn't get the ACK back in time, it will retry the data and then cause an inadvertent collision with the ACK.

So a short ACK timeout could cause a problem, but a long one probably won't. Ooohhh... unless the corresponding duration value of the original packet (preceding the ACK) isn't long enough.

The OP said he may get a chance to get me a capture tonight. I look forward to it!

Gene

P.S. Can the ACK timeout be set manually?

This is good. I think our thread is really going somewhere now.... I will see if I can make some experiments this weekend with one of the seldom used legs of our WISP.

Adam

P.S. Can the ACK timeout be set manually? Yes

ACK timeouts are something that most enterprise AP's don't have so I can't experiment with it, but I would definitely try setting it manually. Somewhere in the 50's sounds like a good place to start.

Gene

My ack-timeout was dynamic at 33 and earlier it was around 60 so I manully set it at 55 and tried changing channels. After changing channels 3 times it pulled the same trick so that didn't fix it although it was a good thought.

Keep thinking!!!!!!!!!!!!

Since my last post which wasn't very long ago I have been trying all kinds of settings on channel 1 and the only setting that got the clients asssociated was turning on (compression). I'm not sure how this helps but is the first time that I ever used this. Can anyone confirm? I will try this again and see if I get the same result. Say a prayer before you do it!!!

I have came to the conclusion that what I said is a bunch of crap but if you disable all prism clients and only allow atheros clients to connect it always connects them after making changes. I am going to try another test by disabling atheros clients and see what it does.

Disabling atheros clients doesn't help, it still wouldn't connect most of the time. So far all of my attempts have failed.

I have this on pc, with AR5212 AND also with AR5213 generic PCI cards, set to 802.11g, clients atheros 5213, access point - not rb, and after 3 days I see ........... nobody....... ( the ap has only 3 to 6 clients, connecting randomly, 4 at most times.) I changed this from a ap in client mode, with a asus router, and ....... now it's working.

This is my first to do something like this, and i hate it, but i changed the ap - meaning removed wireless curd, put an ap - put it on ethernet to the router, and now my clients register fine. Don't know why is that. Disable and re-enable, about 10 times, got me 1 client, but not the rest. Haven't been that pacient to enable hundreds of times. But for you who like to do that, i think you could try a script..... put a enable - disable - enable - disable how many times you want it....... .
I have seen the problem on rb112/2.9.41 ( 2.9.38, 2.9.42). Sorry to say, I changed it with a pair of rb133c. Wireless card is the same, r52, so i guess it has nothing to do with it.
And also sorry to say that, But i'll hate to say, I will replace one of the atheros cards with a senao 2511cd, wich has a far better sensitivity than ALL the atheros i've seen. On at least 3 specific configurations. I cry for bandwidth, but while it's enough, and rock solid, i won't change it.

My ack is at most times close to 65.
I have clients with atheros and realtek 818x (8181 and 8186) Different from atheros, realtek is rock solid, stable. It disconects only when unplugged from ac. Atheros clients disconnect randomly, some of them, and reconect within seconds. Distance max 2.5 km, with 12db omni at ap side.

It must be some kind of ack value thing. So what i read here, if you watch your ack on ap, and set it to a comparable value to that of the "good times", and fixed, it should be fine. I will surely try this.
Question is: why a simple ap with realtek, works better than MT, in this specific configuration....

The problem is in the client, which doesn't properly interpret the disconnection message, and thinks it's still connected. If the manufacturer of the client could improve this, there would be no such problems. We could improve the driver, to send more disconnection messages to the client until he finally understands that there has been a disconnection. We will work on this.

If this was a problem with the client (CPE) then why does the problem go away when people change their AP? If it were just a problem with the client, this wouldn't be localized to just a few AP models.

The more I think about this the more I think this isn't the problem. If this were the problem it would occur with ALL AP models on the tower. Here is why:

If an AP gets rebooted normally, such as after a config change, it should send out disassociation frames to let the clients know. However, if the AP gets a hard reboot (power off / power on) then it won't send these frames. If the clients were hanging on as you say, then whenever ANY AP gets a hard reboot this association problem would exist, and it doesn't seem like anyone has reported that happening.

No dice.

Gene

the client keeps sending frames even if he has been disconnected, while it should already start looking for the ap (which it doesn't). this is a known problem, and as I said, we will work on a workaround because there is no way to fix all the clients that have this problem.

The problem with your theory is that even a laptop 100 feet away from the tower can not associate during this issue. So apperently if it is the clients causing the problem then it is shutting the radio on the tower off somehow. Because you can reboot the client all day and it won't connect. Something is getting confused during association and causing ap to crash otherwise the atheros clients or cleints that have been rebooted would go ahead and connect. Thanks

thank you Normis.. thanks thanks thanks.!!!!!!
I am glad you guys had stepped in. Just to know you are working on it. makes me feel all warm and fuzzy inside

I have a small question.

the client keeps sending frames even if he has been disconnected, while it should already start looking for the ap (which it doesn't). this is a known problem, and as I said, we will work on a workaround because there is no way to fix all the clients that have this problem.

The problem we are taking about occurs when the card is reset for any reason, so in the case of a reboot, the client has not been disconnected, I do show in the logs that the AP has unknown data from device and decided to deauth, the question is why doesn't the client just authenticate, there is no reason for us to deauth a cleint that has a matching SSID?

again.. thanks for being here.

Illini,

I completely agree. This is not a problem with the clients. When I get a capture I'll be able to narrow it down. I may stop by your location on my way to Chicago and do a capture. I'm hoping to get a capture from another WISP before then so I can work on it.

Gene

Surfnet,

An AP should disassociate all clients before a soft reboot so that would be normal. If a client doesn't know that it is has been disconnected and keeps trying to send data, it will timeout after 64 (default for most clients) retries. 64 retries would take around a second to happen. After it realizes that the AP isn't responding, it should know that it is disconnected and attempt a reassociation.

The problem with the explanation is that a new (previously not connected) client can't authenticate while the AP is having this problem. This is an AP problem and is trying to be covered up with an incorrect explanation and placing the blame elsewhere.

Gene

I forgot that I have an rf sensor and could put it between cleint and tower to see whats happening. I'm not sure what all info it will give but I will try to get a capture today. I know it will show all clients and access points that it can see and will also show who is causing dos.

Good luck on firguring it out Gene. Just let me know if there is anything that I can do to help you.

Normis, I also wanted to thank you for stepping up to help us with this problem.

the client keeps sending frames even if he has been disconnected, while it should already start looking for the ap (which it doesn't). this is a known problem, and as I said, we will work on a workaround because there is no way to fix all the clients that have this problem.

another small question.. . If it is indeed the CPE causing the problem, then how come putting a Senao prism card in the AP solves the problem?

My theory is that it is the association process and apperently prism and atheros do this in a different order or look at different values first and causes a conflict. Like I said only my thoughts on this not real facts. To my knowlegde people with all atheros are not experiencing this problem and like you said the senao prism card does fix the problem although through recent installs I have found that newer atheros clients won't connect to the prism. So switching to the prism is no longer an answer and I would rather have the higher powered card anyway.

I too am happy to see you, Normis!!

The problem that we see can be triggered by anything simple, such as using the wlan card to sniff, and then returning it to duty.

Anything that causes it to change it's operation state will cause it to go haywire.

Adam

This is a data point, not sure if it is important but I too have experienced this and it is frustrating and a bit concerning. I am running pure MT AP's and Clients, all running NSTREME and polling. My clinent cards are all WLM54G's and my AP's are SR2 and Engenius cards both of which see this problem on occasion. Changing from Antenna A to B appears to solve the low DB and connection problem but then upload speeds go to hell so that's not a solution. Another WISP in my area with about 1,200 customers has seen the same thing. His network is a mixture of clients, MT, Zinwell, CB3's, etc. He has been fixing his AP's by using PRISM cards. Not an option for those of us that have invested in pure MT boards and using NSTREME.

We need a workaround quickly.

have you read this?

http://forum.mikrotik.com/viewtopic.php ... 119#p77119

I set my ack-timeout to 90 but I'm waiting until later tonight to attempt changing channels. This tower only has 12 clients so it doesn't show this problem everytime you make a change but if you change to channel 1 and then to 11 it usely won't connect to the clients without cycling the interface a few times.

isnt that a clue.. that the problem only occurs on 1 and 11..I had an issue where If I chose the nosiest channel, the people would connect, but they of course would have throughput problem. If I choose the nice clean channel, I had to do the enable dance for a while to get them on.

to me this means that the atheros is able to ignore noise easier than ignoring CPEs.. I dont know, but it sure does sound like a clue.

It is strange because I usely have better success running on the same channel as a competitor that is about 2 miles away. They are using 2 180 degree sectors and always run on 3 and 9. Generally speaking 3 is my best channel. Makes me want to scratch my head with a beer. Wait that was a good idea!!!

There has to be some default setting that the prism uses to determine how long to wait so what is that setting and can it be applied to the atheros. I logged into another system with senao 2511 and it doesn't allow for setting ack but does show up blank under status. Does anyone know what prism uses to determine this other than csma/ca ?

Is there a way or maybe a script that could be written which would allow the ACK timeout to be dynamic but with a maximum? i.e. I want my ack timeout to be dynamic up to 80 but not to go above 80...

Sorry for the bad news bad setting ack-timeout to 90 on my ap didn't do any good. I still see the same issue when changing channels. This has to be the most annoying problem when it works so well when they are connected buuuuuutttttttt then they don't connect. Mikrotik PLEASE HELP US. And thank you in advance.

I cannot stress enough that the next step is to see a packet capture of the attempted association. I will ship a laptop ready to go if that is what is necessary. I'm not trying to make a $ on this... I'm just trying to help. I want to be that hero of the month.

Gene

If you could solve this one, I think you might be in the running for hero of the year.

Adam

illiniwireless:

ACK must be set on both sides.
what is the hardcoded ACK timeout in that senao 2511?
there *has* to be an ACK timeout (otherwise nothing works) and it's usually set to something equivalent of up to 3km (although most indoor APs these days ship with up to 300m for performance).

give us packet captures and we can (probably) tell you what is wrong!
use the "/ tool sniffer" functionality and save to disk. make them available on the web or something.

I'm stonewalled on several deployments now. I have an assload of Tranzeo boxes that I really need to use for CPE devices.

Would using the EMP-8602 cards correct the problem? I know there have been debates and when these cards first came out they were garbage. Mikrotik has said more recently that the problems have been corrected.

Sten,

The ACK timing shows to be 30us on my end when I log into one of my towers with a 2511 card on the AP. I guess that is what the Prism card AP forces the client cards to when associating. That seems kind of short considering I have one customer on this tower who is 13.85 miles from the tower. The test client I am using is a MT 133c board with a R52 installed sitting several hundred feet from the tower.

In reading some other forums i.e. StarOS it seems that the problem is affecting EVERYONE. Prisim does not play well with Atheros.

Does anyone have a functioning AP using an old 2511 card that can confirm the issues do not happen with the 2511?

Sten,

The ACK timing shows to be 30us on my end when I log into one of my towers with a 2511 card on the AP. I guess that is what the Prism card AP forces the client cards to when associating. That seems kind of short considering I have one customer on this tower who is 13.85 miles from the tower. The test client I am using is a MT 133c board with a R52 installed sitting several hundred feet from the tower.

... And as a result almost all of your traffic over the air is completely unnecessary retransmissions.
An 802.11 AP cannot tell the client what the ACK timeout is. This is something that must be configured on each side separately.
There is almost no administrative information passed between two 802.11 radios (for easy compatibility). Of course there is administrative overhead, but that is something completely different.

Good luck!

I know that the ACK timeout thing keeps coming up, but an ACK timeout problem doesn't have much to do with the symptoms that I have heard.

If the ACK timeout was wrong there would be serious issues once all devices associated.

I have wondered if the problem exists because too many devices are trying to associate at the same time. If we could bring up the CPE's one at a time (I know, next to impossible) it may show us something.

Gene

MT Tech:

I can prove the theory about the CPE still thinking it is connected is incorrect. When this issue occurs and the AP card is enabled. I can take a Tranzeo CPE-200-15 that is mounted at my residence and point it to the AP and reboot it. The AP shows up in the list of AP's with a signal reading of -72 but the CPE will not associate to it (but the Atheros based CPE's will). It is like the AP is not allowing associations from Prism based CPE's. I can unplug the CPE for 20 minutes, plug it back in and it will still not connect to the AP. Then I start the disable/enable process on the atheros card for anywhere from 2 minutes to 30 minutes and when all the CPE's start pouring in on that lucky time you enable, the CPE I was rebooting will connect right up.

I hope this helps get the issue resolved. I am working on getting a sniff but have been dealing with other issues so I haven't had time.

has anyone tried setting preamble=long on these units?

I just sent a capture over to GTHill from the CPE end showing both behavior's of when the AP is working fine and the CPE associated and when the AP is not allowing associations. Hopefully he will be able to make something from it.

Sten:
I believe someone had attempted to change the pre-amble and reported back that it didn't seem to help. Not certain though.

Could you send me the captures as well?

netslist@gmail.com

I did receive the captures today and will spend some time on them this afternoon.

Although mismatched preamble can cause compatibility problems, they are a go / no go thing, not intermittent.

Gene

Yes, if the choices were "Long" or "Short" but in routeros, you also have the choice of "Both" which may have an inadvertent effect.

I have tried long only, short only and both with no success.

quick question - shoot me if it's a dumb one. Does this problem _only_ occur when the SR2 is used, as the subject says ?

I believe it is when using any Atheros based cards as an AP. I have read that the R52 also exhibits the same symptoms. I have 3 new antennas now with SR-2 cards and have not had the problem yet...... but these antennas have less than 10 clients each.

I have had this problem with SR2, XR2 and CM9 cards. It seems like the more clients the worse the problem. I currently have 12 on an XR2 and it does show signs of this problem but nothing like the SR2 did with 25 clients.

This is definitely a bigger problem with more users on the node. I was thinking that is had to be 40 users, but I am having issues with nodes with 30 people on them.

Here is an interesting look a the problem.

Over the weekend I got a call the the AP was having trouble. I logged in at there we 22 out of 34 clients on the AP. But none of them could pass traffic. Not even enough to keep the hotspot connection going, and then since I got to the problem after an hour or so.. the DHCP lease ended, and the clients could not even get an IP. Also this node a 4 mikrotik clients on it. I can MAC ping those. They were getting about 1 out of 100 packets and that was 550ms or worse.

How can this be a problem of an overload? There are only 12 people that weren't on. And why was no one able to pass traffic? I looked at the ACK time and it was at 90.

So I started clicking on clients in the reg table and choosing 'add to access list' which reset the connection. After this they did not come back.. I did this until all the clients were gone. Then I proceeded with the disabling and re-enabling of the wifi card. while MAC pinging the mikrotik client

I don't have to wait to see all the clients on, all I have to do is see a good constant 2 -5 ms ping time. Once I see that, all is well.

So how can a few prisms trying to associate with the atheros AP cause the AP to not pass any traffic to any of the clients.

If this is truly the case, and mikrotik has no answer, I don't know how we can continue to use them. I mean, at the stage all someone has to do is get a couple of prism chipsets and try to get on our network, and we die.

I can accept that prisms don't work well with MK, I can accept if I have to change them all to get them to associate, but I cannot accept the prism having the ability to destroy a perfectly good working AP, with the clients already on it.

I have poured over the captures today. Unfortunately I don't have the full captures yet, but Mukah is sending me some more.

Here is what I have found so far:

During normal operation, the CPE's send a Probe Request to the proper SSID. The next packet shown (remember, I can't see packets from the AP until I get more captures) is an Authentication packet from the CPE, which is just a formality. Nothing really happens there under most circumstances. The next packet is the Association Request frame from the CPE. This is correct and everything looks good. Even though we can't see the Association Response from the AP, we know that it works because the CPE starts sending traffic and all is well.

The next capture was when Mukah reboots the AP and captures the CPE attempting to connect. In this case, all I can see is the CPE sending Probe Request frames with no other frames following. One of two things are happening at this point. One, the AP sees the Probe Request and doesn't respond, or the AP sends back the Probe Request incorrectly and the CPE doesn't like it so it just keeps sending Probe Requests. This will be answered when I see the capture from the AP.

Conclusions:

This is evidence that it is not a CPE problem since the Probe Request frames are correct and exactly the same in both captures (successful connection and unsuccessful connection). I did notice that the duration value of the frames changed for no explainable reason during the successful capture. Duration values are representative of the ACK timeout value and ACK data rate. I am wondering if the varying values are due to ACK timeout negotiation on the part of the AP. I know a few of you have thought about the ACK timeout value as a possible problem. I cannot rule it out at this point.

I'll keep everyone updated as to my progress.

Gene

P.S. If I had one of these AP's and a CPE, would that be enough to test it or would I need a full set of CPE's? I'll buy or borrow some stuff from you guys for testing if I can reproduce it in the lab.

4 Filling Up the Access Point Association and Authentication Buffers

Many access points do not implement any protection against these buffers being overflowed and will crash after an excessive amount of connections are established or authentication requests sent. This applies to software access points as well; for example, an OpenBSD 3.1-based AP.

I googled for "4 Filling Up the Access Point Association and Authentication Buffers"

I found an article
http://www.awprofessional.com/articles/ ... Num=9&rl=1
----------------------------------------------------
4 Filling Up the Access Point Association and Authentication Buffers

Many access points do not implement any protection against these buffers being overflowed and will crash after an excessive amount of connections are established or authentication requests sent.
-------------------------------------------------------


This suggested that the AP will crash.. this is not the case we are having, we dont crash, we just cant get CPEs to connect, and the ones that do connect, cant pass traffic. Perhaps the atheros chip itself crashes, but not the Mikrotik. I guess that would explain why you must reset that card for it to work again.. that is if you feel that scanning or frequency usage is reseting the card. I dont exactly know what it takes to reset a card.. but again, if this is indeed the problem, then we have a much bigger problem.

I know Ubiquiti reads this forum, perhaps they would like to give their 2 cents on the matter.

4 Filling Up the Access Point Association and Authentication Buffers

Many access points do not implement any protection against these buffers being overflowed and will crash after an excessive amount of connections are established or authentication requests sent. This applies to software access points as well; for example, an OpenBSD 3.1-based AP.

Resembles Windows(r) startup with many items, many processes hang and system freezes for a while, unless some changes in registry are implemented

If the theory of buffer overflow is correct, then one test should prove it correct or false. Set all the clients on access list and block them. Then enable the clients one by one. If the theory is correct, then all the clients should eventually come up. Tried this, with no results. Maybe access list control is not the answer. Maybe Mikrotik has to set a time interval among the CPE associations.

Another theory is that CPEs usually automatically associate with other APs in the area once the main AP is not available. Once the CPEs are associated with other APs, they will not easily disassociate from the other APs and reassociate with the main AP unles they are rebooted or so. Thus, the CPEs when associated with other APs may actually cause interference for other CPEs tying to connect to the main AP, and if they have more powerful EIRP than the main AP, then they may Kill the APs signal as well and only the enduring more powerful clients may associate.

One thing that I have experienced is that the clients furthest from the main AP, ie with least interference from other CPEs, never have any problems reconnecting. The main AP here being situated in town and the far clients on the outskirts where only one or two more SSIDs can be picked up from competition or Indoors WiFI equipment.

Anyway, all are just theories and may be nonsense.

All of my clients have the ssid manually set to the tower with the problem. You can also go reboot the clients antenna or use a laptop at the tower and still not be able to connect without disabling and renabling ( and this may take several attempts) the wireless card on the routerboard that is being used as an access point.

Same thing here.

Let's not forget that the problem is prevalent with the R52s as well.

Adam

what happens if you disable the wireless for more than the few milliseconds you are jiggling things ? Leave it off for like 60 seconds and then reenable it. jsut a thought.

Sam

I have tried many different timing strategies, from as fast as a can to letting sit for 1 hour.. no change, it appears that it works withing the first 20 seconds or so after enabling, and after that if the people arnt on, they will not get on again, unless you disable the radio.

Same thing here too. Seems as though we know almost instantly.

Adam

one of the weird things with this problem, is that most of the times you get nobody or everybody on, but sometimes you will get about 1/2 to 3/4 of the people on, but no one can pass traffic.

this is the thing that really puzzles me. I have node with 14 people on it, it never has the problem. So I would think that once the AP has 20 out of the 30 people on it, then it could get the other 10.. but that doesn't happen. You have to start all over again.

Also this problem can occur when everyone is on and happy. I get calls that no one can pass traffic, and I log in and see everyone, but no traffic passing.. again I have to reset the card to get everything working.

In the beginning I used to just leave the card alone for hours, thinking it was some crazy interference, I have taken a spectrum analyzer out to the problem nodes, during the problem,. and I have seen no interference, I am way out in the mountains, and we are the only wisp around the immediate area, so the air is really clean.

Identical Situation here as well.

We too are out in the country, there is nothing around, noise floor is near -102, and yet the problem persists. I see it with my XR2, SR2 and R52.

Adam

Gene have you got the samples back yet. Just wondering.

Thanks

I haven't as of yet, but Mukah emailed me and let me know that he would have them soon.

Gene

Hi

We are having this problem as well, we have two RB532 to with Mtik R52 cards on one particular tower. Other towers with fewer clients have had little or no issues, including areas with high noise.

This is a relatively noise free environment, no competitors.

AP #1 - 120 deg sector on one with various clients including 20+ Orinoco USB Clients (Hermes chipset) and a mix of tranzeo CPE and CPQ's (40 Clients)
AP #2 - Horizontal Omni with mostly Tranzeo CPQ's and a few CPE's (40 Clients)

When we have a power glitch (as we did this afternoon) we lose all/most of the clients. For the second time in a row now we have been unable to get them back until evening. Our tower is West of the clients, I'm wondering if solar interference could have an affect. Once the sun starts to go down I can get them back, the only other explanation is the customers are turning off some of the radios??? Certainly possible with USB Clients.

I usually play with the tx-power output and leave the ack timeout at a set value of 300-400, eventually I can get the clients back on. Lately it's only been in the evening.
The interesting thing is once I get AP #1 working I can usually get AP #2 working as well, something seems common between the AP's. As I said waiting until evening (which sucks) seems to allow the clients to connect.

I don't think its an ack issue, I get the deauth messages in the logs.

If the CPE's were not working properly one would think disabling the AP radio for a few minutes would force the CPE's to start hunting.
If anyone has a script for temporarily fixing this, that would be great.

I have noticed that the USB Clients do not connect at all when we are having this problem,while some of the other units will connect. Of course through-put is almost non existant during this period.
The only solution I can think of to this problem would be a UPS or 12V battery attached to the power injector on each radio. If we can minimize the issue then the problem is somewhat mitigated.

Other than this issue the Mikrotik's are by far the best AP's we've ever used.

I'm having that exact same issue when the town and surrounding area's power goes down and then back on. It's that sudden, all at once reconnection or authentication of the wireless clients that must cause this. Only if there is more like say 15 Prism based clients on a AP. My symptoms further is as you described regarding connecting but no passing of traffic etc.

Albie

Who is the closest person to Central Arkansas having this problem? I know a guy in OK and one in IL having this problem, but is anyone closer? I'll come look at it for free to get this thing figured out.

Gene

To MT.

Enough is enough.

I am going to test another OS which can run on RB532 with RB52. Whether it solves the problem or not, I shall declare the result on this forum and MT should accept the truth.

We rolled out a new repeater operating in WDS this afternoon.

R52 on the station WDS side, and an SR2 on the client AP BRIDGE side.

The R52 synced right up to the WDS back at the pole... But the SR2 side, which had six clients on it, took forty or so enable / disable swaps before it would start to pass traffic and register all six people in correctly.

I am bringing this up because the poor little SR2 was operating in a noisey environment, looking over the Santa Rosa Plain. Noise floor at -87.

I have observed that they do seem to do more poorly when in a noisier environment. But... We need to get to the bottom of this. It happens with R52 as well as SR2 units.

I just installed one RB532 and SR2 today in a quiet place, noise floor at -123. I will be experimenting with many other client radios throughout the weekend to see what I can find.

Adam

I realized this as well, at night time when there is less noise (-93 DAYTIME / -102 NIGHT), the SR2 takes only a few enable/disable to pick up all the clients. Is it possible that the SR2 has some extra filters to utilize only the available unused frequencies within each channel? If so, then maybe, the SR2 is not finding enough available frequencies to be able to associate the clients. ie not enough throughput for at least 1 Mbps.

Does MT know anything about this? Please advise, and if yes, then we should try to find a way to bypass this feature. Maybe what MT should do is test an SR2 with many SR2 clients! But yet again, the R52 is doing the same. So MT may try the R52 as AP with 30+ R52 clients and in a noisy environment! Not just in the lab. Or else you may try it in the lab with a 100 other CPEs to cause noise on all channels.

Just a suggestion.

Gene have you found anyone close to you yet and have you got the other results back yet? I know that it isn't a setting problem so it has to be in the software and since this is the issue I think it will be hard to figure out. When the problem happens the ap is no longer talking so I don't think you will get any info from a scan. I'm starting to think that the driver for the card is probably more likely the problem.

I think it speaks volumes to say that Mikrotik reads this forum, and so does Ubiquiti, and I am sure both are reading this thread. The fact that they refuse to say anything to me means they have nothing to say.

I guess they are afraid to come out and say..'Yes our card or our software has a bug and it gets choked by to many prism cards attempting to connect to it'

Me personally, I would have much great respect for a company that can admit their problems and stand up to the plate and try to work them out, god knows they have enough of us with the problem to be able to get data from.

Illini,

It probably is a driver problem, but I still think that I will see what is actually happening by performing a capture.

Gene

try wl54ag for backhaul 5.8Ghz and XR2 for distribution your problem will solved.

I guess they are afraid to come out and say..'Yes our card or our software has a bug and it gets choked by to many prism cards attempting to connect to it'

I have similar problems and no Prism cards, so I don't think prism cards are the key, I could be wrong.

"try wl54ag for backhaul 5.8Ghz and XR2 for distribution your problem will solved."

Damn, and why didn't I think of that? Jeeze maybe if this first time poster read the forum before opening his mouth it would have stayed shut.

There is no difference between using SR2, XR2, CM9, 8602, WLM54G or 54AG. Atheros does not play well with prisim.

I did try making the client radios R52s in RB133c, and I still had the same problem.

Adam

Not a bad idea, really considering how so many people are going through the same thing.

Adam

LOL. They deleted my post.

But I am not upset but happy, coz it proves me right, just like the 2.5GHz issue.
Also, everytime my posts get deleted, an update with a solution is released.
This must be a sign!
Thx Normunds!

PS when is your next MUM in South Africa. I missed the training coz MT's email was sent too late! I couldn't leave my work coz I had no time to make arrangements for my absence. I received it only five days before the course!

By the way, do you sell any advanced training course material?

I read your post before it was erased. I thought it was good. Ha ha ha.

Can anyone explain WHY Atheros and Prism cards don't like each other under all circumstances?

We recently swapped out the BriLan stuff which used Prism cards for MikroTik units in our A.P., and discovered a few new issues that arose from this hardware swap. Some people benefited tremendously, while others had to be completely re-worked....

Just migration pains, really.

Adam

I read your post before it was erased. I thought it was good. Ha ha ha.

Thx Adam. I just turned the other cheek. But unfortunately I only have two!

Great point regarding Atheros and Prism.
We always used to have issues regarding different brands, different chipsets, different firmwares, etc. But why does a wifi enabled laptop with Windows(r) OS simply connect to anything? Must be drivers! Windows(r) is known to have the advantage of compatibilty vs the stability of Linux.

Maybe we should try Windows(r) 2000 professional on RB230 with 128 MByte Ram We can disable all unnecessary services.

you obviously all have different kinds of problems, which you should report to support. somebody said that their clients don't reassociate, and now everyone with similar issues think they all are caused by the same problem.