Atheros client re-association problem revisited

sdischer · Mon Jul 09, 2007 6:19 pm

I have been following the previous closed post viewtopic.php?f=7&t=15647&hilit=sr2+problem but feel it is necessary to reopen this subject.

In summary, based on my experience using Atheros AP's, Atheros clients, on an all Mikrotik network running NSTREME. If an AP has less than 10 clients on it, there are no problems. Once you hit about 15 clients, the problem begins. On powering up the AP, clients will associate in groups of five or so, all registering with -95 signal strength. If you have a client at the base of the tower or very close, they will associate immediately with normal signal strength, usually. From that point forward, about every 5 seconds we see clients associate then drop off. This repeats in groups of five or six. Sometimes 2/3 of the clisnts will associate and then all drop off. Unless you take some action, they will never stop associating and reassociating.

Some things that appear to fix it:

1. Change the antenna to TxA-RxB. Everyone associates with normal signal strength but uploads are slow and client Tx CCQ is bad. Not really a fix.

2. Change from 802.11B to 802.11B-G. Sometimes this solves the problem.

3. Rapidly enable and disable the interface. Probably the best solution from my experience. I even wrote a script to do this every 2 seonds. Works sometimes.

This is what I have observed so far. Here are my hardware evolutions:

Original
AP - Senao NMP8602
Client - Compex WLM54G
Problem first seen when AP hit 17 clients

First Change
AP - Replaced with new, unused Senao NMP8602
Client - Compex WLM54G
Problem continued

Second Change
AP - Replaced with SR2 and new 532A RB and replaced sector antenna, coax, poe
Client - Compex WLM54G
Problem continued

Third Change, different sector, different clients, different tower, same problem
AP - Replaced with XR2 and new 532A RB
Client - Compex WLM54G
Problem continued

I read throughly the previous post about this problem viewtopic.php?f=7&t=15647&hilit=sr2+problem. Having experienced and fought this problem myself with the fear of losing tons of customers I believe most of these people posted with the same problem based on similar symptoms.

This is an urgent situation, more urgent that version 3 Beta (unless that fixes it), more urgent than updates to the Dude, etc. If I could run 2511 cards and fix all my woes I would but Prism won't do NSTREME and I am fully invested in MT and NSTREME so it is too late to turn back.

Help MT, please help us solve this asap. I can provide data and assistance from the field if needed.

If you post to this topic, please post factual information and not opinions about anyone, any company, etc. Resolution is more important than expressing emotion.

jwcn · Tue Jul 10, 2007 3:53 am

Nothing to do with emotion.

1. You were using Compex cards on your clients. Have you tried using a Compex card on the AP side.

2. I have no issues using Atheros (All Ubiquiti based) radios as long as I use all SR radios.

3. The problem resolves if you use the old Senao NMP-2511 cards.

sdischer · Tue Jul 10, 2007 4:21 am

All Compex is not something I have tried but that's a good idea. 2511's are not an option because they are prism based and they won't do nstreme which I run exclusively. If it weren't for nstreme I would gladly drop the 2511's in because they definately don't have this problem.

jwcn · Wed Jul 11, 2007 2:35 am

I've had no issues with Compex cards but I run them exclusively in B mode only.

sdischer · Wed Jul 11, 2007 4:19 am

What is the maximum numbers of users on one AP? Are you running nstreme?

hytanium · Wed Jul 11, 2007 6:09 am

What are your NSTREME settings?

I had a similar problem.. changed from best-fit to dynamic-size and things are working well now. I have polling also enabled.

sdischer · Wed Jul 11, 2007 6:53 am

That has worked for me too, sometimes, other times no.

MyThoughts · Wed Jul 11, 2007 3:49 pm

For myself I have experienced odd issues like this in the past. My observations were:

NSTREME preforms worse if the noise is higher in the area. Especially in PtMP enviroments.
Almost all of my odd issues like yours have been a result of outside influence, stong background noise, etc.

Something I have noticed is that the noise floor reading in ROS, could be quite good at -99, or -105 yet on a spectrum analyzer it shows strong non-802.11b,g signals that caused enormous problems when I tried to operate near their frequency. So just becuase the noise floor is still resonable it doesn't mean their isn't something else interferring.

A few questions I would have for you:
1) Does the problem persist without NSTREME?
2) Have you tried different channels?
3) If you are using all Mikrotik and Atheros, have you tried 5MHz or 10MHz channel sizes?
4) have you checked the area for other stong 2.4GHz signals?
5) do you have anyone on the AP that would be considered a borderline connection (Tx/Rx of <-83)?
6) Do you have the AP rates locked down or is it running at default settings?

Cheers

sdischer · Wed Jul 11, 2007 7:46 pm

A few questions I would have for you:
1) Does the problem persist without NSTREME?
Not sure. Since it is PtMP I am runing nstreme throughout so to do such a test would be difficult.

2) Have you tried different channels?
Extensively. This tower is out in the middle of nowhere.

3) If you are using all Mikrotik and Atheros, have you tried 5MHz or 10MHz channel sizes?
No. I don't have any experience with this. What are the benefits/drawbacks?

4) have you checked the area for other stong 2.4GHz signals?
Yes, I am getting decent spacing from other signals.

5) do you have anyone on the AP that would be considered a borderline connection (Tx/Rx of <-83)?
No.
6) Do you have the AP rates locked down or is it running at default settings?
Default. MT states time andtime again default is the best setting. I have no opinion.

Cheers

Thu Jul 12, 2007 11:44 am

have you tried to run Nstreme without polling? Disable polling on the AP and check the results.

cal361 · Thu Jul 12, 2007 3:58 pm

I am not using NSTREME, but am using 10mhz channels and that has helped us out alot as alot of 802.11 stuff gets ignored because I am listening to 10mhz channels instead of 20mhz.

Also, if you look at my post history you will see that I had tons of problems for a while. Most of the problem was clients dropping every few minutes and reassociating. My solution was rather unexpected. I discontinued using The Dude and my problems went away. My AP is now happily serving 30 clients in 10mhz channels and each one is set to an AP limit of 2.5M down/390k up. Working great. Now I need to add a few more APs.

VistaVox · Fri Jul 13, 2007 12:53 am

I too have been having this re-association problem. When the AP is rebooted, or power is cycled, many clients will not re-associate. AP is 8602+(on 175ft tower) with clients using approx 30% Tranzieos, 30% CB3s, and 40% MikroTik w/r52 cards. The problem began recently when we added a few additional users, putting us somewhere around 20 on that AP, but problem effects all users not just the recent additions. 2 other towers with similar setups do not show the same problem, but they are only serving 10 or fewer each.

Notes: The AP is running a virtual SSID in addition to the primary one. The only thing I've noticed that helps at all is to shut down The Dude before the reboot and not open it back up until after clients have associated, but this has not worked every time.

Please help, we are loosing customers over this.

sdischer · Fri Jul 13, 2007 4:22 am

I have heard this comment about the Dude several times. Wonder what the Dude has to do with it? Is is possibly the SNMP polling the dude does of the AP? The Pinging? Anyone have a clue about this?

sdischer · Mon Jul 16, 2007 12:48 am

Today I experimented, I changed frequencies and to get the clients to re-asssociate, I changed from 2.4-B to 2.5-B/G. Then enabling and disabling the interface they all came back on. Unfortunately going back to B was not as easy but eventually by enabling and disabling, I got them all back on. Disabling the Dude had no affect. I contact tech support and they suggested incrasing the CPU speed, that NSTREME took an increased amount of resources. I checked CPU while the clients were dropping on and off and it never got over 15% so I don't think that is the issue. They also suggested Ver 3 Beta but I am concerned about it in a production environment. I have also heard a lot of upgrade problems going from 2.9.

peavys · Tue Jul 17, 2007 9:44 am

Uh Oh,

I had this problem on non-nstreme APs and eventually gave up on Atheros. The problem makes the AP useless. My purpose was to deliver higher speeds through 802.11G. The only way I was able to do this was to use an external radio and just use the Mikrotik to manage other functions. I wonder if using one of the other router-oses like Antcore would work.

I thought this problem had been resolved or did not exist with nstreme. I've been rolling out 5G APs on my towers, but have a max of 14 clients on any given AP. Looks like I'm heading for trouble again. Gag. Anyone know of an prism based 802.11a card?

nickb · Tue Jul 17, 2007 8:16 pm

Uh Oh,

I had this problem on non-nstreme APs and eventually gave up on Atheros. The problem makes the AP useless. My purpose was to deliver higher speeds through 802.11G. The only way I was able to do this was to use an external radio and just use the Mikrotik to manage other functions. I wonder if using one of the other router-oses like Antcore would work.

I thought this problem had been resolved or did not exist with nstreme. I've been rolling out 5G APs on my towers, but have a max of 14 clients on any given AP. Looks like I'm heading for trouble again. Gag. Anyone know of an prism based 802.11a card?

Yeah I see what you are saying. Unfortunately I think we are pretty close to starting to look for another vendor due to these issues too. It's been revisited over and over again on these forums, but support keeps blaming this on CPE/Noise. One common thing that I have read in a number of different posts is that if they use an AP from a different vendor - even Linksys - that this problem does not occur. I submit that how can the problem be CPE/Noise if someone can replace the AP with equipment from any other vendor - even SOHO crap - and the problem does not show up?

I'm currently working on a way to test this myself, but I have not been able to do so at this time - so that's based purely on what I've read in posts on this forum.

kbyrd · Wed Jul 18, 2007 7:32 pm

This problem happens when you change any setting on the wireless card and click apply with more than 10 or so clients. I have done many test to see if there is a setting that can help with this and found none, but i will try and explain what i have found so that someone can fix it.

First off, from what i have found is that it is a problem with mass cpe's trying to reconnect at the same time. I tested this by moving about 30 customers off an AP(Mikrotik with Prism card) to another AP(Mikrotik with Atheros card) one at a time. Prism cards seem to be the fix for us since we dont use nstream, just normal ap handing dhcp, but i want to use long range cards i still put them up to test. I moved all 30 clients 1 at a time and all 30 were registered and great signal, no noise, and working great.I changed the radio name(not SSID) by 1 character and clicked apply the 30 clients droped off and 5 came back and log stated getting the old sent deauth msges. I disabled and re-enabled wireless card over and over again till they all came back up then i clicked hide ssid and back to 5 clients. unhid ssid still 5. after playing with it i found that you can change any setting and hit apply and drop the clients or get them to come back up, ex. one time i changed the ap back and forth from 2 channels and they eventually came back up. I put all the clients back on the original prism ap and started over again all 30 move over fine 1 at a time. then i put them back on original ap and disabled the prism ap and changed the SSID of second ap to that of the prism ap and got 5 clients and sent deauth msges in log, so it looks like the atheros+mikrotik gets bugged out from having 10 or more clients try and connect at same time(and we changed to every different atheros card we had, sr2, compex,ect..).

here is my fix for this problem though not a true fix but if the tower drops clients its already fixing itself before you know there is a problem.

i made a script called "watcher"

:for i from=1 to=1 do={
/interface wireless monitor wlan1 interval=1 do={
:if ($registered-clients < 10) do={
/interface wireless disable wlan1;
/interface wireless enable wlan1;
}
}
}

then made a scheduler that was set to startup, has interval of 00:00:07, and event watcher

I put that on tower and changed a setting the clients droped to 5 but then it fixed its self after about 5 mins.

hope this helps.

sdischer · Wed Jul 18, 2007 7:51 pm

Good data points, thank you kbyrd.

Here's a brief summary of what I believe to be true based on our experience and these posts:

1. This is a Atheros AP to Atheros client problem.
2. The problem is not limited to NSTREME, as kbyrd is not using NSTREME.
3. The problem is not limited to MT AP to MT client.
4. The problem seems to be related to any MT AP with more than 10 clients.
5. Rebooting the clients or the AP does not fix the problem once the AP starts this ASSOC/DIS-ASSOC cycle.
6. Any change to the AP that causes clients to dis-associate will trigger this problem.
7. There is no coorelation between noise and the problem, we see it on towers near town and out in the woods.
8. This does not appear to be a CPU resource problem as the CPU never goes over 15% during the assoc/dis-assoc cycles.

An idea for a work around would be a script to put on clients to create a random dlay such that they do not all try and associate at the same time. From what kbyrd has seen, if you manually bring the clients back one at a time the problem doesn't occur.

jose · Thu Jul 19, 2007 2:04 am

I have better results re-associating the radios by putting DFS Mode to "radar detect" in wireless options, scanning the interface worked also although with less success. of course it is an atheros problem because all my cards are CM9. I see this issue for a long time in this forum.

before I had a wrap-star-os AP without any problem, the card was atheros with CM9, so I am thinking seriously to deploy some wrap-star-os APs in the busiest places.

hey, i won´t change MT for my long P2P links, neither for my Mikrotik core router

peavys · Thu Jul 19, 2007 4:23 am

I tested this about 18 months ago and at that time in my system there were only CB3s at customer sites, which I don't think are Atheros chipset. The only Atheros part was the SR2 or Senao Equivalent ( forget the part number) at the AP. Both failed.

BTW I had a previous post removed where I was suggesting a method of testing and mentioned a competitor's name explicitly. Perhaps they will let it stay if I just say: If you are currently experiencing this problem and could swap just the CPU with something else it would nail down for certian if it is an Atheros chipset problem or MT problem. Jose's post seems to indicate it is an MT problem but a clear cut test would be nice.

sdischer · Thu Jul 19, 2007 5:58 am

We are going to try a test. We are going to turn off Default Authenticate and remove all MACS In the ACL and add them back in one at a time. Our theory is that the problem has to do with too many clients trying to associate at the same time.

Another option which could be scripted easily as a workaround is to set the MAX STATION COUNT to 5, then increase in groups of 5 until you get up to a sufficient number.

I am going to try this tonight after midnight during our maintenance window.

jober · Thu Jul 19, 2007 8:30 am

If you are using MT as CPEs you could, Maybe make a script so if it losses connection it will turn off the radio for a minute and then back on so that the others can connect. Maybe in sets of 10 a minute apart.
I know this isn't a real fix but maybe it will work like the AP side script fix from the other side.
It just seems the fix is to not let all the CPEs connect at the same time.

Thu Jul 19, 2007 3:09 pm

we looked at one of the clients AP which has approx 35 clients with many at approx -85 signal.
When we disable/enable the wireless card, then to get them all to connect, it seams best to have a dynamic ack. fixed near to max (350-408) and preamble-mode set to 'long'.
It appears that some clients are making giant amount of radio traffic trying to reconnect to the AP and blocking others from connecting to AP and blocking traffic to connected clients.
We will try to find a way how to handle them better.

sdischer · Thu Jul 19, 2007 3:21 pm

Changing max station count seems to help but is not a workaround solution as every time you incriment and apply, it disconnects all the clients there defeating your purpose.

I tried turning off default authenticate, disabling everyone in the access list and then enabling them one at a time. Unfortunately I ran out of time and couldn't really test this although it shows some promise if we could script it.

Kbyrd and I are considering setting up a test environment with as many wireless clients as we can find, CB3's, laptops, MT boards, etc, whatever we can find and do some testing that way in a lab environment. I hate to keep ticking off clients and all of my customers seem to want to use the internet 24x7 so maintenance windows aren't much use.

sdischer · Thu Jul 19, 2007 3:24 pm

Good observation Uldis, I think you are on the right track. There are several of us on this forum that are more than willing to contribute time, resources, whatever to help figure this out.

jose · Thu Jul 19, 2007 4:43 pm

The best solution is MT accept that there is a problem, it is pathetic seing to a lot of users trying to solve a vendor problem

sdischer · Thu Jul 19, 2007 4:57 pm

I understand your frustration Jose and I empathize, but in the spirit of resolution I do not mind dedicating my resources to solving a problem.

If we were dealing with some other manufacturers, there would be no response, no forum, no interaction with the developers, etc., just a one way call to a tier 1 outsourced agent in a far away country that only knows how to tell me to power cycle.

I appreciate the interaction and the responsiveness from MT and will continue working with them as long as they will work with me.

jober · Thu Jul 19, 2007 10:44 pm

I wish I could help more but I only have a max of 10 client per AP after changing to 5mhz and adding more APs. But before I did that I did have 20 clients on one AP and I never had this problem. Also I just asked Gerard at Shelby Wireless if he has this problem and he said NO! He has 20 to 40 or more clients on most of his APs. He has well over 300 clients on his network. Most of the clients are MT but he also has LS2's and PS2's.

Fri Jul 20, 2007 9:02 am

The best solution is MT accept that there is a problem, it is pathetic seing to a lot of users trying to solve a vendor problem

Uldis = MT

enrique · Fri Jul 20, 2007 1:48 pm

The best solution is MT accept that there is a problem, it is pathetic seing to a lot of users trying to solve a vendor problem

normis
uldis
sergejs

they all are=Mikrotik, and believe me thay are great. If you have any problem they will be there to solve it.

regards,

Fri Jul 20, 2007 2:14 pm

there is actually at least 3 more here, actively trying to help people.

VistaVox · Fri Jul 20, 2007 8:11 pm

:for i from=1 to=1 do={
/interface wireless monitor wlan1 interval=1 do={
:if ($registered-clients < 10) do={
/interface wireless disable wlan1;
/interface wireless enable wlan1;
}
}
}
then made a scheduler that was set to startup, has interval of 00:00:07, and event watcher

Until MT gets this resolved this is by far the best workaround I've seen, I plan to implement this sometime this afternoon, will let you know how it went.

Thanks kbyrd

jober · Fri Jul 20, 2007 9:35 pm

:for i from=1 to=1 do={
/interface wireless monitor wlan1 interval=1 do={
:if ($registered-clients < 10) do={
/interface wireless disable wlan1;
/interface wireless enable wlan1;
}
}
}
then made a scheduler that was set to startup, has interval of 00:00:07, and event watcher
Until MT gets this resolved this is by far the best workaround I've seen, I plan to implement this sometime this afternoon, will let you know how it went.

Thanks kbyrd

But didn't you all say that if you make any change to the AP you have the same problem? If so wouldn't you still have the same problem?
Why not do some thing on the CPE side so they connect at different times.

normis,
Could you or one of the MT guys make a script for the CPEs that would do this?

JR · Fri Jul 20, 2007 10:01 pm

suggestion:
it would be rude if polling says [shutup] and wait until your turn, yes i know who you are (by ACL), but just wait a minute, please! before i connect you.

ORDER!

kbyrd · Sat Jul 21, 2007 1:52 am

:for i from=1 to=1 do={
/interface wireless monitor wlan1 interval=1 do={
:if ($registered-clients < 10) do={
/interface wireless disable wlan1;
/interface wireless enable wlan1;
}
}
}
then made a scheduler that was set to startup, has interval of 00:00:07, and event watcher
Until MT gets this resolved this is by far the best workaround I've seen, I plan to implement this sometime this afternoon, will let you know how it went.

Thanks kbyrd
But didn't you all say that if you make any change to the AP you have the same problem? If so wouldn't you still have the same problem?
Why not do some thing on the CPE side so they connect at different times.

normis,
Could you or one of the MT guys make a script for the CPEs that would do this?

if you change anything it has a chance of causing the problem again, but if you run the script once the clients are up they stay up until the ap reboots or you have to do a channel change or maybe even a few clients powering back up at the same time.

The script helps for when a tower reboots by itself or you change channels and all the clients don't show back up.
It will not keep it from happening, but it will keep it from staying down. I have been dealing with this problem for a while and my script has saved alot time trying to get them back up myself.

The problem with putting it on the clients side is that I and many other people have different
hardware for clients. I have a tower that has all cb3's for clients so i cant put a script on them.

iron4umx · Sat Jul 21, 2007 4:02 pm

It's just a reflection to what could be the cause of the problem:

Hum... it seems that there is a problem with the way the system is managing the connections for the clients, since Routeros let's you tweek all of the settings, it seems that by default the managment is somewhat not apropriate for multiple users in some scenarios.

Does anybody know the standard protocols for this?? I guess they should be explained in the ieee thingy boop, in any case... we could use that protocol (If there is such a thing) or we could create one that suits our needs, using some kind of script, there should be a work arround for this.

A sugestion for the MT team:

It would be a good Idea to revise the drivers for the atheros cards, since there could be a problem with them, there could allso be a problem with the firmware in the atheros cards... this problem looks like a really low level issue, I guess atheros should be informed abbout this behavier, it seems that there is little we can do abbout it

jacsa · Sun Jul 22, 2007 5:10 am

Same problem, see the attached picture: the last 15 stations are connected for a quite long time, but the others are kicked off frequently.
Hardware: RB532A+SENAO NMP8602 in B mode, but I have the same experiments with SENAO NL2511MP (Prism!) even if I use WRAP 2C board with MT.

jacsa · Sun Jul 22, 2007 5:17 am

Oops, I forgot: the clients are Edimax 7206-s (Realtek 8186).

nickb · Thu Jul 26, 2007 6:31 pm

we looked at one of the clients AP which has approx 35 clients with many at approx -85 signal.
When we disable/enable the wireless card, then to get them all to connect, it seams best to have a dynamic ack. fixed near to max (350-408) and preamble-mode set to 'long'.
It appears that some clients are making giant amount of radio traffic trying to reconnect to the AP and blocking others from connecting to AP and blocking traffic to connected clients.
We will try to find a way how to handle them better.

Yes, it has worked very well since these settings were applied. Only once has there been a "slow down" situation where people start calling saying "this is slower than dialup!". Doing a disable/enable resolves the situation, and all stations reassosicate as they should.

rodneal · Thu Jul 26, 2007 9:29 pm

I've been having this problem for 2 years now.
The only resolution has been to use a different vendors AP - this of course defeats the purpose of using MT with the visual reporting capabilities.
I have switched CPE vendors several times and have lost lots of customers because of it!!!!
I have used the "dynamic" ack settings and have found it to be VERY inconsistant.
Not a good permanent fix!
The scripting looks interesting - so I'm gonna try it. I just implemented the new XR2 into several APs. I have them both on 180ft towers and they both have 10-12 customers on them.
They are using the exact same boards - 153 - and they have exactly the same configuration of bridges onboard - 2 5.8. The SNR is relatively the same on all connections and the distance of CPE is comparable. They are 35miles apart and connect to the same primary bridge system of towers - 6 hops out (We have 70 towers and over 100 APs in the field - primarily MT and Deliberant). They both have 2.4 WDS connections for smaller APs on the edge. One works most of the time and the other is a total pain in the butt. I have changed all cable and cards and antenna several times. I fired Tranzeo because of the problem and now we use Zcomax and Deliberant CPE. The problem is less but still an issue.
I'll report back about the scripting.

rodneal · Thu Jul 26, 2007 10:25 pm

I've been having this problem for 2 years now.
The only resolution has been to use a different vendors AP - this of course defeats the purpose of using MT with the visual reporting capabilities.
I have switched CPE vendors several times and have lost lots of customers because of it!!!!
I have used the "dynamic" ack settings and have found it to be VERY inconsistant.
Not a good permanent fix!
The scripting looks interesting - so I'm gonna try it. I just implemented the new XR2 into several APs. I have them both on 180ft towers and they both have 10-12 customers on them.
They are using the exact same boards - 153 - and they have exactly the same configuration of bridges onboard - 2 5.8. The SNR is relatively the same on all connections and the distance of CPE is comparable. They are 35miles apart and connect to the same primary bridge system of towers - 6 hops out (We have 70 towers and over 100 APs in the field - primarily MT and Deliberant). They both have 2.4 WDS connections for smaller APs on the edge. One works most of the time and the other is a total pain in the butt. I have changed all cable and cards and antenna several times. I fired Tranzeo because of the problem and now we use Zcomax and Deliberant CPE. The problem is less but still an issue.
I'll report back about the scripting.

I tried the scripting - I even set for 3 and not 10 - slowed reconnects but did not fix the inherent problem. I even disabled the the wds edge connect and worked that angle for awhile and same issues reoccurred.
Would love a fix for this!!!!! I like MT and have really invested into this tech - having to buy outside AP really bites. Only solution I know right now tho.

peavys · Fri Jul 27, 2007 8:21 am

Hello MT folks. As Normus has pointed out, several of you have been following this topic. I'm wondering what you know about the subject, and how it might be addressed. Normus you mentioned that MT is "working on" this problem, but I don't have much sense of that what means. Are only support people looking at this, or are your programmers working on it?

Are you:
* doing lab tests
* field tests
* experimenting with software tweaks
* making debug versions of the system that dump data while the failure is occurring to determine what the cause is
* other things...

Do you feel like you understand the problem yet? Does this forum represent a small minority who are having problems, and most people are having success, or is the problem common?

From everything I see here, this can only be resolved by software changes to routeros itself. Is this problem a high enough priority to be assigned to your programmers to work on? If so, when and what do you think the prospects are for a solution? If not, that is still helpful to us to know. All of us are WISPs so this problem is huge for us, but I know you have a diverse customer base and this may not be a big deal in your overall business model. It would be helpful for us to know that though.

If it is not a high priority, would it be possible to pay you to have a programmer work on it?

Thanks,

Corky

Fri Jul 27, 2007 9:28 am

we are already working on it and most likely we will have a fix next week.

tlkhorses · Fri Jul 27, 2007 7:09 pm

Well, I will have to chime in here also. I have been working on this problem for a couple of weeks with no resolution. Replaced everything on the sector including the antenna. Replaced old cpe units with MTK. I have a mixture of MTK and Tranzeo on that sector now. No nstreme, just a regular b AP. I tried the settings Uldis suggested and that didn't work. So looking forward to the upcoming fix.

tk

GTHill · Sat Jul 28, 2007 7:40 am

Since the last forum was locked, I have traveled to IlliniWireless's WISP in the great State of Illinois.

I performed a packet capture and have been analyzing it off and on for quite some time. I'm going to post my results as I observe them. There seems to be a lot going on here. The main capture that I will be referring to is one that no CPE's would connect after an AP reboot. Towards the end, all CPE's associated correctly.

- I have seen two capture from two different WISP's. When comparing the CPE behavior, the CPE does not alter it's packets in any way. The CPE's packets and contents are identical between a successful connection and when the problem occurs

- Approximately 6 minutes before CPE association, there were quite a few cases of the CPE getting to the Association Request phase of connection. This is where the CPE requests actual layer 2 connection. All of the responses from the AP for 6 minutes were "Unspecified failure" which means the AP denied association, but the was no specified reason by the AP.

- At the end of the capture, all CPE's associated one right after the other. There was absolutely no difference in packet content or protocols in use between the failed connections to the final correct associations.

- The AP sends broadcast deauthentication frames. Once the AP stops, the associations start to happen. (I just found this one while posting this. This is HUGE!) A broadcast of deauthentication frames is actually not allowed according to 802.11 standard and technically is a form of denial of service attack.

I appreciate the folks at MT working on the problem. If I can be of any help to MT or anyone else, please don't hesitate to ask.

Gene Hill
CWNE #21

illiniwireless · Sun Jul 29, 2007 11:52 pm

I JUST SPENT THE LAST 4 AND A HALF HOURS DIABLING AND ENABLING THE WIRELESS INTERFACE TO GET MY CLIENTS ASSOCIATED. I FEEL A LITTLE UP TIGHT NOW. PLEASE COME OUT WITH THE FIX SOON!!!!!!!!!!!!!!!!!!!!!!!!!

THANKS

illiniwireless · Mon Jul 30, 2007 2:01 am

Where can you download older versions of the router os? I would like to try some of the first versions for the atheros cards and see what happens. I've upgraded other equipment and made them incompatiable after upgrades so I think there is a possiblilty that moving way back might help. I have noticed that some people are not experiencing this problem and there has to be a reason for it.

Thanks
Brad

nickb · Mon Jul 30, 2007 6:38 pm

Where can you download older versions of the router os? I would like to try some of the first versions for the atheros cards and see what happens. I've upgraded other equipment and made them incompatiable after upgrades so I think there is a possiblilty that moving way back might help. I have noticed that some people are not experiencing this problem and there has to be a reason for it.

Thanks
Brad

You can't download older versions, and it doesn't matter anyways because I've tried it as far back as 2.9.27 with no difference in symptoms. I have a few older versions than that, but they are all MIPS and the AP I was testing on is x86.

peavys · Mon Jul 30, 2007 7:04 pm

Additional info:

I have been migrating to 5.8 Gig sectors which means Atheros cards. When I had just 1-2 customers, speeds were ~ 7Mbits to the tower with 10Mhz channels. I have sectors with 4, 6, and 11 customers. Speeds decline percipitously as the number of subscribers goes up. With 11 customers speeds are ~ 2.5Mbits, with the other two the speeds are ~ 4.5Mbits. I spent most of the night testing with 10mhz channels and with / without nstreme and the underlying issue remains. I suspect that whatever causes the disconnects may be causing the slowdowns, and my tower with 11 customers is about to start failing outright when I add a few more customers.

One nice thing about this experiment is that it shows this has nothing to do with noise, because there is no 5G noise in my area.

Corky

jober · Tue Jul 31, 2007 7:08 am

Do all the clients have connections in the -60s?

peavys · Tue Jul 31, 2007 7:51 pm

I have seen this problem on other towers and signal is not the main issue, at least not in the prism chipset world. My signals run -68 to -80. When we hooked up the first few clients we tested and found that people work well into the high 80s, so I set the cutoff at 80. I've done some more experimenting since then and found that part of the issue is that the sectors interfere with each other when they should not. This may not be related to this topic's subject, I should open a new thread for it.
-- Corky

illiniwireless · Thu Aug 02, 2007 6:31 am

Not much to say other than everyone seems to be waiting patiently on the fix or everybody went on vacation and does anyone else have ony other good information that might help in fixing this problem. HELP US!!!!!

I would like to add one other comment to kbyrd , thank you for the script. I had a location lose power today and this got all the clients back online without my help. Thanks again kbyrd. A little extra info. Depending on how many clients you have on a radio you will need to tweek the script accordlingly but it works great. Although you are right, it isn't a fix.

ericsooter · Thu Aug 02, 2007 5:36 pm

I saw this on the new 2.9.45 firmware list. Does this have something to do with it:

*) implement hw-retries setting for wireless;

-Eric

Thu Aug 02, 2007 5:45 pm

I saw this on the new 2.9.45 firmware list. Does this have something to do with it:

*) implement hw-retries setting for wireless;

-Eric

Yes, read this announcment:
http://forum.mikrotik.com/viewtopic.php?f=7&t=17523

rodneal · Thu Aug 02, 2007 7:28 pm

YYYYYYEEEEEAAAAAAHHHHHH!!!!!!!!!!!

illiniwireless · Thu Aug 02, 2007 7:33 pm

THANK YOU !!!!!!!!!!!!!! I've loaded this on 3 towers and so far it is working GREAT!!!!

sdischer · Thu Aug 02, 2007 8:15 pm

Setting ACK to 350 FIXED IT with version 2.9.44 as well. Thanks Uldis, thanks MT! Sleeping better tonight.

peavys · Thu Aug 02, 2007 11:13 pm

Short ACK times in a WISP is a bad plan. It causes a lot of unnecessary retries and packet loss. Let's hope the fix MT provided proves out. Has anyone else tried it yet?

sdischer · Thu Aug 02, 2007 11:36 pm

I edited my post, I should have said 350 not 35. My bad. You are right, 35 would be a bad idea...

peavys · Sat Aug 04, 2007 6:24 am

Initially it worked, but the way people connected made me nervous; very much like what I saw 1.5 years ago when I last tried this. Clumps of people would connect then back off, then go forward. Initially however it did connect everyone so I thought it was working if a little shaky. Later I tried playing with some other settings to work on other problems. Several times everyone came back up. Then I made some little change (ack time fixed at 350 I think) and only about 8 people came back. After that, nothing I did would bring them back, and I tried a lot of things. This is all exactly what I saw 1.5 years ago. Finally I climbed the tower in the dark and put a prism card back in the unit, all was good as usual.

There is a new prism chipset out that supports 802.11g/a that I would like to ask MT to support. I've been suffering with Atheros for 1.5+ years and they have just been unsuitable on APs. I notice that Ant-c0re seems to have the same problems, judging from posts on their forums. I suspect we are kicking the point of the sword and Atheros is just never going to work on the AP side, though it seems OK for the clients.

http://www.conexant.com/products/entry.jsp?id=53
http://findarticles.com/p/articles/mi_m ... i_n8708783
http://www.embeddedworks.net/wlan/oem_m ... 11abg.html (3rd item down)

Corky

illiniwireless · Sat Aug 04, 2007 6:44 am

I haven't seen any problems yet and I even have about 50 clients on one of the ap's with the atheros card in it. Everytime I make a change they come right online. Maybe that card went bad peavys.

npbrasil · Sat Aug 04, 2007 4:56 pm

Yes, the 2.9.45 version is rock solid here too. Kudos to Mikrotik team!!!

sdischer · Sat Aug 04, 2007 5:13 pm

If you are reading this post, don't waste your time with the ACK=350 workaround, go here:

http://forum.mikrotik.com/viewtopic.php?f=7&t=17523

Looks like it is really fixed. Thanks.

swetland · Tue Aug 07, 2007 12:27 am

We are still having the same problem with several of our users retrying. We are using tranzeo cpq19 at the client side, mostly because that is what was installed and we do not want them all to have to change out.
We are using the Microtik Ubiquiti card on the AP side. Before the latest update the radio was dropping customers and retrying constantly. After the update only a few users are doing it still. Our question is what type of authentication are you all using. We think it might be a problem with the WPA authentication, but we are not sure.
Thanks

sdischer · Tue Aug 07, 2007 12:42 am

PPPoE and MAC ACL's.

airstream · Tue Aug 07, 2007 1:00 am

Same here, MAC ACL and PPPoE for client Auth. No WPA or WEP.

Who is online