'N' associations

[mrmike]

In version 1.0.2 and 1.0.3, Iget teh 'N' associations coming back on the HGA2400 and DLink bridge 810+ (plus 1 wrap right now). I have to reset the card for all to get re-associated. The cards on on the 4 port war system, 802.11b/g mixed, 12 miles, 10 dB override, interbss and short preamble on (though it doesn't matter). I even put the ping watchdog on the 2400's this morning, and they still go to 'N' state. Any ideas?

[lonnie]

Try it with B only. Make certain that you disable AP power Saving and try with SuperAG off. Remove InterBSS since it allows users to talk direct. In version 1.0.2 and 1.0.3, Iget teh 'N' associations coming back on the HGA2400 and DLink bridge 810+ (plus 1 wrap right now). I have to reset the card for all to get re-associated. The cards on on the 4 port war system, 802.11b/g mixed, 12 miles, 10 dB override, interbss and short preamble on (though it doesn't matter). I even put the ping watchdog on the 2400's this morning, and they still go to 'N' state. Any ideas?

[dastring]

Do you still recommend turning off AP Power Saving for this? I thought that we always needed to have AP Power Saving on for APs?

[tkerns]

When are we going to see a fix for this?

[lonnie]

AP Power savings should be turned on if you know that your clients are not poorly designed. A poorly written driver will inform the AP it is power saving, which means the AP starts to buffer packets, but it will never let it know it has come out of power saving, which means that the AP will run out of buffer space, which means that the AP will crash.

[lonnie]

I'm not sure about this question. The problem is not with our AP since it works with a properly written driver as you find in our V3 systems.

It will get fixed when the other manufacturers fix their driver. Or it will get fixed when you replace those poorly designed units with WAR clients.

I am not working on a fix for the cb3, etc units. We work great with our AP and client combination. I take the view that it is not a problem I created. I might have uncovered it, but it is not my problem and will take a software fix for the client driver.

You are in the support hands of the people who made and sold you the client.

When are we going to see a fix for this?

[tkerns]

This is the attitude that will be your downfall.... the whole world is wrong and you are right... well Lonnie then when are you going to FIX your CPE.... WRAP ver 2. IT fails also so fix it then.

It is a problem with YOUR AP... the atheros driver will not play well with prisim CPE, including yours.

This is the same attitude you used about the AP showing the WRONG IP to MAC. It could not be your problem, the radio displays what it see.... right.
Well you were wrong then too.
http://forums.star-os.com/showthread.php?t=5724

You have 7 years experience.. I have 30.... anyone who believe they design perfect software is a fool....

This problem with "N"'s IS YOUR problem, take time and investigate it.

Why did WRAP ver2 run fine with the SAME CPE's and ver3 locks up with most every client showing an "N" state.

If it were 1-2 clients going to N then I would say it is a CPE issue. When the AP STOPS allowing associations and disassociate nearly all clients and STAYS in this state for hours, then IT IS AN AP PROBLEM. Why does forcing a reset to the radio fix it and clients reassociate.... IT IS AN AP PROBLEM.

Accept it YOU have a bug with atheros and prisim, now if you still say it is a CPE problem, then I want a fix for my ver2 clients, they go to "N" state also.

As far as your belief that you solved the problem with WAR to WAR...(you said this in another thread) this only shows you have tweaked the driver to meet your needs.

[lonnie]

I deleted everything I wrote in response to you and started over. It is better that way. I have no time for this discussion. If you have trouble with a client unit, talk with the manufacturer and have them fix it. If you feel my AP is the cause of the trouble then don't use it.

If you have tried my AP and my Client then you already know that it is an awesome combo and does not have the issues you see with other units. We worked real hard to make them both as good as they can be.

The bottom line is that you are wasting your time and mine by trying to get me to fix problems with other systems. When you have a problem where my AP does something wrong with my client I will fix it, but just stop asking me to fix the world. I won't do it. I can't do it. And more importantly, I should not have to do it.

As for the IP/MAC issue, it was precisely what I said it was. The AP did not make up the IP, it merely reported what it saw. The simple fact that it should not have seen the IP is not an issue to the discussion. I quite correctly described what our code did.

Since when did I say I have 7 years TOTAL experience? Talk about jumping to conclusions and making up statements to support your view. I have never said we make perfect software BUT I have said that some problems are not our issue and that we are not going to fix them. You can belabour your point all you want, but it will not change anything.

My AP and Client work very well together. Use them or don't. I'll not lose any sleep over the fact that you will not be using my stuff. You got into your current situation because you used the other gear in the first place. If you keep making such mistakes because you buy equipment based on price and not on the networking ability you'll never have a network for the demands of Internet as it is shaping up. We need VOIP and here the V can stand for Video or Voice. We are busy working towards the future and quite frankly that is all we have time for. Trying to fix an issue so that more cb3 units can have their life extended and even so that more can be sold is just not what we are all about. Sorry to disappoint you.

One last time-- I did not make the problem. I might have provided a system that showed the problem exists but it is not my problem. We fixed our code and it is the job of the other guys to fix their code. You seem to demand more of me than the other guys. That is not fair and I refuse to stand for such treatment.



This is the attitude that will be your downfall.... the whole world is wrong and you are right... well Lonnie then when are you going to FIX your CPE.... WRAP ver 2. IT fails also so fix it then.

It is a problem with YOUR AP... the atheros driver will not play well with prisim CPE, including yours.

This is the same attitude you used about the AP showing the WRONG IP to MAC. It could not be your problem, the radio displays what it see.... right.
Well you were wrong then too.
http://forums.star-os.com/showthread.php?t=5724

You have 7 years experience.. I have 30.... anyone who believe they design perfect software is a fool....

This problem with "N"'s IS YOUR problem, take time and investigate it.

Why did WRAP ver2 run fine with the SAME CPE's and ver3 locks up with most every client showing an "N" state.

If it were 1-2 clients going to N then I would say it is a CPE issue. When the AP STOPS allowing associations and disassociate nearly all clients and STAYS in this state for hours, then IT IS AN AP PROBLEM. Why does forcing a reset to the radio fix it and clients reassociate.... IT IS AN AP PROBLEM.

Accept it YOU have a bug with atheros and prisim, now if you still say it is a CPE problem, then I want a fix for my ver2 clients, they go to "N" state also.

As far as your belief that you solved the problem with WAR to WAR...(you said this in another thread) this only shows you have tweaked the driver to meet your needs.

[skyclimber]

I'm sure Lonnie is right since i have war clients and they work perfectly. I got also a lot of problem the first time i replace my WRAP AP for a WAR AP. But i know the problem is my CB3 units. I have other problem with them because they are very sensitive to noise when compared to Atheros cpe. I don't have the money to replace them now but i know they are the problem. I'm waiting for a low cost single atheros CPE from VALEMOUNT because all their stuff work as expected.
Is it dangerous for the WAR AP if we disable POWER SAVING to make them working with CB3 ?

thanks

Louis

[dastring]

Bottom line is that CB3s are crap.... and they ALWAYS have been. Marginal at best. Inexpensive for sure, and that allowed the little guys to get in to the business. But, if small WISPs are going to hope to compete with the big carriers that are rapidly moving to "packet" systems, then they need to take a chapter from their book and build reliable systems and get rid of the "cheaper is better, short-term" mind set.

[tkerns]

You have missed the POINT..... it is not just a CB3 issue....

WRAP clients with ver2 StarOS go to "N" state and stay there. SO then StarOS ver2 is broke as well.


My whole argument is that the AP will disassociate clients and then NEVER let another client re-associate for HOURS..... not until the radio ON THE AP is forced to reset. I have logs and screen captures that show this. Any client that shows with a "C" will have ping times in the 3-5 SECOND range. When this happens.... more than 90% of the clients are "N".... this is not just a couple clients going to "N".... the whole AP becomes useless.

If it were just a client problem, then the AP would allow new clients to re-associate, but it does not.

[tog]

It is not dangerous at all to disable power saving, in fact I recommend always doing it. It has done nothing but cause problems for me.

Lonnie recommends leaving it enabled if all of your clients support it, in other words if all of your clients are running v3.

I personally have NOT ever observed any downside at all to disabling AP power saving, not even the little jump in latency I'm supposed to see (?) when the client goes away for a moment to do a background scan.

CB3s suck, a lot. I say again, if you have or had an AP that worked ok before and made your CB3s happy (maybe a v2 AP?) I would leave it alone and just put a new 2x-cloaked v3 AP up beside it to put new clients on. And then of course stop buying any more crappy CB3s.

I like real practical solutions that involve working with what I've got available to me rather than waiting for somebody else or trying to convince somebody to change or fix something for me. The above is just that.

[lonnie]

Tim, you have also missed some information. I am speculating that some CB3 units do not like the disconnect they receive when they are idle and they hammer the AP with re-associate attempts. This causes much noise at the AP and that causes others to drop off and they hammer the AP. This builds unitl nothing can associate. A channel change is required to make them stop, since they stop receiving beacons and only then do they stop the bad behaviour and switch to a normal association mode.

If you used an older v2 driver, yes it does have the issue, but that was fixed in the latest beta. If you are using v2 or even V3 with some defective CB3 units then the CB3 will rule and wreck it for everyone.

Now lets drop this. As I said I exposed the problem but I am not going to fix it. The system works the way it works because we needed it to be that way. We did not make it work this way in order to kill CB3 units since our units were initially affected as well. The big difference is that we fixed our units. Now please, go and demand support from the other guys. We are not able to help you any further. I am getting a bit annoyed with people who are angry because another company will not fix their product. I can understand the anger but I do not accept it being directed at me.

I guess the bottom line is you get what you pay for. If you paid a very cheap price and get poor design and no support then don't be blaming me.

You have missed the POINT..... it is not just a CB3 issue....

WRAP clients with ver2 StarOS go to "N" state and stay there. SO then StarOS ver2 is broke as well.


My whole argument is that the AP will disassociate clients and then NEVER let another client re-associate for HOURS..... not until the radio ON THE AP is forced to reset. I have logs and screen captures that show this. Any client that shows with a "C" will have ping times in the 3-5 SECOND range. When this happens.... more than 90% of the clients are "N".... this is not just a couple clients going to "N".... the whole AP becomes useless.

If it were just a client problem, then the AP would allow new clients to re-associate, but it does not.

[bobbyc]

Well let me throw this into your speculation about the CB3 problem. Majority of my clients are CB3s. I have a WAR4 with 3 WLM54G APs that together total of ~50 CB3 cpe's. This WAR4 has been up 2+ months and the only times I've rebooted it is to upgrade the OS. I have never seen the N problem on this tower. The CB3s' will behave just like any other cpe... when the idle time gets to 6 minutes, it goes to N for a second or two and back to C.


The tower is on a remote hill and there is no noise.

Again, 2 months of service and no problems with the CB3 clients.
I speculate the N problem is noise related. Lonnie is probably right about his CB3 problem, but the problem might be brought on by noise at the AP... not the standard 6 minute disassociation/reassociation.
Bob C

[bobbyc]

I retract what I say above. I did some testing this afternoon and got a system that has been stable to start going to 'N'. Changing channels and rebooting didn't seem to immediately help. Only after messing with it for 5 minutes and then leaving it alone for a minute or so, the 'N's went to 'C' and could start pinging the CPEs.
Bob C

[bobbyc]

The tower that I have yet to have a 'N' problem is v1.1.0 build 1338. I changed channels around this morning on that tower because I made some changes to the backhaul. The clients would reassociate just fine with 'C'.

It will be interesting to see if after I upgrade the tower to the latest release, it starts to have the 'N' problem.
Bob C

[bobbyc]

OK just disregard my last 3 posts.
Lonnie is right.
Bob C

[skyclimber]

Hi Guys,

:confused: All my CB3 3054 CPE will recover from N state when the user will try to access Internet. BUT the main problem is that we are unable to remotly access a client from internet when it appear to N. Even when we set AP power saving to off, a client who need to access is office computer from home is unable to proceed when the office CPE appears "N" state.

By the way what is the purpose of "N" state appearing even when Power Saving is disabled?

thanks Louis

[jeff]

Lonnies theory may be correct, but based on what I have seen it only explains some of the problems.

I have gone through about a dozen combinations of V3 revisions and settings and found that any given board/location combination seems to have a firmware/channel/settings combination that will mostly work most of the time. This of course is the worst support problem you can have since some customers are fine and others have intermittent problems that they may not report until they are thoroughly fed up and when they do contact you it is hard to narrow down the problem.

Because of the above results I decided to try some other atheros based systems. I tried Mikrotik and Ikarus on a wrap and a compex atheros based ap. The types of problems that I saw with V3 did not appear using the other systems.

Conclusion: It is not an inherent atheros vs. everything else problem.

Opinion: V3 as it stands now has become a semi-proprietary system. It works fine with itself, but you are on your own with anything else. I would suggest adding this to the description since at least it will cut down on all the people who get ticked off when they figure it out on their own. This also means that Hotspotting should probably be dropped from the planned feature list for V3. Without a higher level of compatibility a V3 atheros based hotspot will just cause endless support headaches. I have had issues with a laptop that has a dell wireless card in it. Never bothered to check what chipset, but if dell shipped me one they probably shipped a couple of hundred thousand others.

V3 without a doubt has the best throughput we have seen of any system we have tested, but it does have limitations relative to its competitors when used in a diverse environment. I continue to believe that it is the fact that the driver has been so tightly tuned for performance with other V3 systems that has caused the loss of interoperability. For all I know the other vendors that seem to work have put in specific fixes when set to "B" only just to keep backwards compatibility. This seems like an excellent compromise since nobody is going to be looking for high throughput using "B" modulation, but everything shipped over the last 5 years supports it.

Who knows, with Tony hard at work on a major driver update he might just tweak the right thing and the problems will go away. In the meantime it is user beware. If you are running a multi-vendor network stick with v2 and a prism based radio unless you want to play a game of V3 atheros Russian Roulette.

Hopefully none of the above information will be considered inappropriate for this forum. I am simply trying to pass on information that would have saved me a lot of wasted time if I had known it in advance.

P.S. is there any chance that the v2 driver for the prism could be compiled and made to fit? Yes the performance is worse and there is no upgrade path, but it would let people move up to WAR without breaking what works now. Just a thought??

[bobbyc]

Because of the above results I decided to try some other atheros based systems. I tried Mikrotik and Ikarus on a wrap and a compex atheros based ap. The types of problems that I saw with V3 did not appear using the other systems.

Interesting. I just saw a email on Judds list this morning that claimed otherwise. I can't quote it without their permission, but this person basically claims that Mikrotik with atheros AP also has problems with CB3 (prism 2.5) clients. The clients will dissapear off the association screen, or 1 or 2 clients will stay connected with a -95 signal... all the while any atheros clients will stay connected.

Bob C

[lonnie]

I saw that as well. From direct customer feedback I also get the scoop and it seems everybody is having trouble with CB3 whether they are Atheros or Prism based. Our CPE unit will be out in 12 weeks and thus we are moving ahead and find very little motivation to provide backwards compatibility.

As I've said, get the other vendors to fix their product. I suspect they cannot or will not. I know for certain it is a driver issue because we had to fix our own client side code to not have the logic bugs. It was real hard to track down so we do wish the other guys luck. And to stop any further requests, no I will not say anything more about the problem. That is their job to find and fix such bugs.

Interesting. I just saw a email on Judds list this morning that claimed otherwise. I can't quote it without their permission, but this person basically claims that Mikrotik with atheros AP also has problems with CB3 (prism 2.5) clients. The clients will dissapear off the association screen, or 1 or 2 clients will stay connected with a -95 signal... all the while any atheros clients will stay connected.

Bob C

[jeff]

Interesting. I just saw a email on Judds list this morning that claimed otherwise. I can't quote it without their permission, but this person basically claims that Mikrotik with atheros AP also has problems with CB3 (prism 2.5) clients. The clients will dissapear off the association screen, or 1 or 2 clients will stay connected with a -95 signal... all the while any atheros clients will stay connected.

Bob C

We have very few prism based clients and it is possible I did not run the test long enough to be conclusive. I ran each for about 24 hours using the latest release code.

[jeff]

I saw that as well. From direct customer feedback I also get the scoop and it seems everybody is having trouble with CB3 whether they are Atheros or Prism based.

The reason we don't use the cb3 is that many revisions suffered form a driver problem on the radio itself. They would associate to a higher powered access point and stay there no matter what the SSID was set to. The tranzeo prism based radios fixed this and I have never caught a tranzeo associated to anything but the specified ssid. The few times I tried cb3's or Interepoch clients I inevitably caught them associated to a neighbors linksys. The cb3 may have shipped in quantity, but it is an amature attempt at best. Having cb3's fall off of an association list seemed pretty routine when we tested them. The real test would be to see if any changes at the ap could make them come back. If it required a power cycle at the customer end it was probably not the same problem we saw. The fact that the atheros radios stayed associated also throws water on the idea that the clients are hammering the ap.

The most difficult one to explain away was a site where a v2 access point had its ethernet port killed by lightning and was being replaced by a V3. The radio was up and I had my laptop associated to it. I could see all the associated clients. I took the cable off of the v2 and installed it on the v3 it powered up to all N associations. I reconnected the v2 and all the clients associated. When I put the V3 back I started moving backward from the most current firmware that I had put on it when it was being assembled. Two revisions back all the clients associated and started to pass traffic. There were no changes in settings during this process. I never saw "N's" on it again, but we started getting support calls about slow or spotty service. Eventually I gave up and put back a v2 prism and all the complaints stopped.

Don't get me wrong I've given up on trying to convince anyone of anything I am just reporting experiences and infering that a V3 hotspot will be a support disaster. For all I know all atheros based access points suffer from the same problem. I did not see that in practice, but I am reluctant to spend too much time testing radios that connect customers, so if it works out of the box for 24 hours without any support calls I've at least done better than I did with V3. All of the above still indicates to me that no matter what the problem is it can be fixed at the AP and someone either has done it or they will.

[jeff]

We have very few prism based clients and it is possible I did not run the test long enough to be conclusive. I ran each for about 24 hours using the latest release code.

My bad here I didn't mean to say prism I meant to say cb3. We do have quite a few tranzeo cpe200's which are prism based. It is possible there are a few cb3's or interepoch 1100's out there somewhere, but I believe we have exterminated just about all of them.

[skyclimber]

I have 20 customers using CB3 3054 NL (Prism 3.0 chipset). 15 associated on a (Atheros SR2 starOS v2 WRAP) AP and 5 associated on a (Atheros CM9 starOS v2 WRAP) AP. All my small network is working like a charm. All my customers can get very high transfer rates. I'm sure there is no compatibility issue between Atheros AP and Prism 3.0 cpe. I'm am stopped for a very weird "N" issue when trying to replace my Wraps V2 for WAR V3 with the same radio cards. Now I need to have a 4 radios board to serve new sectors but have no money to replace all the working CB3 CPE. While i'm waiting and testing, one of my competitor is getting more and more of my potential customers with a bridged 802.11B system. As what i investigated, he is fooling honest people by sharing a crappy 2.5Mb/s link between all is customers. I'm sure the CB3 driver have a part of responsability but...from my point of view, StarOs V2 is very reliable and by far the winner compared to this competitor system even while using PRISM cpe.

Thanks,

Louis

[Ick]

Seems to be a little different but the same as mentioned in these posts.

We had a Wrap 2C with an older flavor of V2 and a Prisim card running 50 clients just fine. Of course the processor would work a little overtime at times. We have no rules or bw at the AP. Just MAC authentication.

Thinking that I would like to lower the processor load on a Wrap, would replace with a War V3 latest version. 1.1.4 I think. When I first installed it, only some of my old Cisco clients would associate. I looked at the short premble, check it, and everyone associated. This was backwards of my understanding, but shruged my sholders and moved on. Processor utilization went down and performance went up.

I new about the problems with V3 and Prisim clients, so I kept an eye on it. 10 days later the N problem showed up again. Only this time no matter what I tried, nothing worked. Some of my Cisco (4 out of 8) clients worked ok. All of my Prisim (CB3, CPE200) and all of my Atheros (CPQ) client did not work. All N associations with no IP. I did notice in the later days, every time I checked on it, it had been up for about 20 to 30 minutes suggesting rebooting. Put the old WRAP/V2/Prisim back in and it worked fine.

It is either an all or nothing with the N problem. With the exception of the Cisco clients, they either all work or none of them work.

I must mention that I had the same problems with V2 at another location. I had a quiet AP with about 30 customers running Wrap/Atheros latest beta as of last Janurary (my guess) that fixed the short preamble problem. Worked just fine for about 7 months, then all of the sudden, associations with no IP address. This was the only location that I could get this combo to work. The War V3 worked at the above first mentioned location for 10 days in a noisy environment where I could not get the WRAP/atheros to work at all.

I seems to me that if this was a client/prisim only problem, that we would see some flakeyness in the clients connecting, like some would, some wouldn't.

I am not disputing that there is a problem with the Prisim clients, seems well known. But why the all or nothing with the Prisim and Atheros clients on V3?

[lonnie]

By your own message here, you say that some of your Cisco work but that all of the CB3, CPE200 and CPQ (all Ubicom based, same as wet11) do not. Does that not count as " like some would, some wouldn't. " ? Our V3 will and some Cisco will, but others will not.

Everybody wants to ignore the subtle facts they are presented with that it is a client issue. They would much prefer that it is our issue so that we have we fix it since quite likely the manufacturer is unable to make a fix. Just keep that in mind when you order the next batch of those defective radios.

Seems to be a little different but the same as mentioned in these posts.

We had a Wrap 2C with an older flavor of V2 and a Prisim card running 50 clients just fine. Of course the processor would work a little overtime at times. We have no rules or bw at the AP. Just MAC authentication.

Thinking that I would like to lower the processor load on a Wrap, would replace with a War V3 latest version. 1.1.4 I think. When I first installed it, only some of my old Cisco clients would associate. I looked at the short premble, check it, and everyone associated. This was backwards of my understanding, but shruged my sholders and moved on. Processor utilization went down and performance went up.

I new about the problems with V3 and Prisim clients, so I kept an eye on it. 10 days later the N problem showed up again. Only this time no matter what I tried, nothing worked. Some of my Cisco (4 out of 8) clients worked ok. All of my Prisim (CB3, CPE200) and all of my Atheros (CPQ) client did not work. All N associations with no IP. I did notice in the later days, every time I checked on it, it had been up for about 20 to 30 minutes suggesting rebooting. Put the old WRAP/V2/Prisim back in and it worked fine.

It is either an all or nothing with the N problem. With the exception of the Cisco clients, they either all work or none of them work.

I must mention that I had the same problems with V2 at another location. I had a quiet AP with about 30 customers running Wrap/Atheros latest beta as of last Janurary (my guess) that fixed the short preamble problem. Worked just fine for about 7 months, then all of the sudden, associations with no IP address. This was the only location that I could get this combo to work. The War V3 worked at the above first mentioned location for 10 days in a noisy environment where I could not get the WRAP/atheros to work at all.

I seems to me that if this was a client/prisim only problem, that we would see some flakeyness in the clients connecting, like some would, some wouldn't.

I am not disputing that there is a problem with the Prisim clients, seems well known. But why the all or nothing with the Prisim and Atheros clients on V3?

[tkerns]

For what it is worth ! ! !

There was another post the other day, not "N" related, but made me think... it was about Spanning Tree, I turned Spanning Tree off about 4 days ago and have not seen the all "N"'s since. We'll see tomorrow morning as Mondays is usually when I see the "N"'s the most.

My thoughts was that when clients are disassociated and then re-associated, spanning tree probably gets very busy updating, and this may lead to the AP not having the resources or power to handle the load of noise, clients trying to associate, and I think at this time "hidden node" issues (several clients that do not hear each other and bang away), etc.

I do see the ocassional client that is disassociated and takes 2-4 minutes to re-associate, but this is usually an inactive client, and not a worry.

[lonnie]

STP is on by default since we have had too many people enable bridging with a loop and it takes their network down. With STP that cannot happen.

We usually try and set startup defaults to options that have the least chance of killing the network on a simple error. Normally we shoot for a simple enable and we have proper selections already in place to make it work for the majority of caes.

For what it is worth ! ! !

There was another post the other day, not "N" related, but made me think... it was about Spanning Tree, I turned Spanning Tree off about 4 days ago and have not seen the all "N"'s since. We'll see tomorrow morning as Mondays is usually when I see the "N"'s the most.

My thoughts was that when clients are disassociated and then re-associated, spanning tree probably gets very busy updating, and this may lead to the AP not having the resources or power to handle the load of noise, clients trying to associate, and I think at this time "hidden node" issues (several clients that do not hear each other and bang away), etc.

I do see the ocassional client that is disassociated and takes 2-4 minutes to re-associate, but this is usually an inactive client, and not a worry.

[jeff]

Everybody wants to ignore the subtle facts they are presented with that it is a client issue. They would much prefer that it is our issue so that we have we fix it since quite likely the manufacturer is unable to make a fix. Just keep that in mind when you order the next batch of those defective radios.

Wouldn't surprise me at all if there are some subtle facts being ignored. That is one of the main reasons that I try to keep as open a mind as possible when trying to debug a problem. The fact that certain firmware will always trigger the problem and that for us it has been an all or nothing experience with the N associations makes it hard for me to believe that the ap has no role. I also haven't been able to create a similar all or nothing situation with any other vendors atheros ap. We have at least 4 years worth of different models and firmware revisions including atheros based radios and we lose all at once.

The spanning tree suggestion is certainly worth checking out. I hate the thought of putting any customers through another test cycle, but if you make it through tomorrow without a problem I will give it a try.

[jeff]

For what it is worth ! ! !

There was another post the other day, not "N" related, but made me think... it was about Spanning Tree, I turned Spanning Tree off about 4 days ago and have not seen the all "N"'s since. We'll see tomorrow morning as Mondays is usually when I see the "N"'s the most.

My thoughts was that when clients are disassociated and then re-associated, spanning tree probably gets very busy updating, and this may lead to the AP not having the resources or power to handle the load of noise, clients trying to associate, and I think at this time "hidden node" issues (several clients that do not hear each other and bang away), etc.

I do see the ocassional client that is disassociated and takes 2-4 minutes to re-associate, but this is usually an inactive client, and not a worry.

This seems like a great thing to try.

For what its worth I'm guessing that if spanning tree is involved it isn't busy/resource problems. The code is probably disabling the ports/mac's it thinks are a problem. We had similiar problems testing the Tranzeo cpq's and didn't figure it out until we were fed up enough with them we decided not to use them. A couple of clients disassociating and re-associating is normal. You can prove normal behaviour by pinging the broadcast address and watching them come back.

[SteveA]

Way back before we saw the light and still considered bridging with STAR-OS a potentially useful tool, we had great difficulties with Spanning Tree on WRAPs. We found that we could keep the psuedo bridges running and the clients associated longer with Spanning tree turned off. If we put a wrap in place accidently with STP turned on, we would have mysterious problems, dropouts, disassociations, etc. Never conclusively proved the relationship, but the evidence was there.

And no, STP was not discovering bridging loops. <grin>

Steve

[tkerns]

Jeff,

Just wanted to let you know the AP made it throught Monday morning without going to an "N" state on 90% of the clients. Would like to hear from others seeing this issue if disabling Spanning Tree helps.

Thanks,

[bobbyc]

Spanning tree doesn't help my 'N' problem. However my 'N' problem doesn't show up unless I provoke it by making/activating changes on the AP.
Bob C

[Ick]

By your own message here, you say that some of your Cisco work but that all of the CB3, CPE200 and CPQ (all Ubicom based, same as wet11) do not.

Lonnie,

Please correct me if I am wrong, but I am thinking that the CPQ's are Atheros based. I could of sworn that they had a CM9 in them.

[skyclimber]

"N" on the field "C" on the table. I've reported "N" problem between WAR4 + CM9 and some CB3 NL3054 on the field. On the table i tested the same WAR4 + five CB3 NL3054 and they are all "C" since almost 36 hours now.

The only change is: I swap a brand new CM9 that seem to be defective (not detected by the WAR4) for another one. Maybe it is a CM9 issue or a Noise issue. (On the tower vs on the table)

Everything is working perfectly with a WRAP V2 + CM9 as AP and 5 customer CB3 3054.

I've not tested STP since i don't think it affects my routed network.

thanks,

Louis

[lonnie]

It has nothing to do with the type of radio card. It is all about the design of the driver and ALL of those units have a common hardware and software base.

Lonnie,

Please correct me if I am wrong, but I am thinking that the CPQ's are Atheros based. I could of sworn that they had a CM9 in them.

[Ick]

It has nothing to do with the type of radio card. It is all about the design of the driver and ALL of those units have a common hardware and software base.

I know I am lining myself up for the firing squad, but I have to ask the question.

From what I read and gather, it is very obvious that there is a problem with Atheros based AP's and cheezy clients. These cheezy clients seem to work well with the Prisim based ap. What are the chances of supporting a Prisim in V3 on a WAR board? (my hands and arms are covering my face for protection)

[tony]

Prism support will be in the next release.

[go.fast]

GREAT NEWS!

I am so happy you guys changed your mind. Any chance you can add in the agere drivers? I have a couple old ap's that can't be changed at this time. They are wraps with agere mini pci card and nasty amps. Nasty amps is the key word here.

Hoping I am not asking too much.....

:cool:

[tony]

At the moment it will only be Prism 2, 2.5 and 3 support. The Agere mini-pci cards are actually TI 1410 cardbus controlers with a built-in card.

[jeff]

Is there a time frame. Lonnie warned that the next release would be significant and several months away.

I also want to add my thanks for this backward compatibility move. This will make my life a lot easier.

[tony]

We will be doing a beta release this week, or next if things work out.

[rafamous]

Yes!

Now I can put V3 on my AP's. I have been waiting for the Prism support myself. I bought a network with all prism based CPE's.

I am using StarOS for clients now. It's much better to be able to log right into the clients radio and do test.

Thanks StarOS Team, keep up the great work.

[DrLove73]

OOOOOOOOOOOO YESSSSSSSSSSSSSS!!!!
There's a light at the end of the tunnel.

Nice, nice, nice, nice, nice, nice, nice, nice, nice, nice, nice, nice, nice!!!

Sorry about shouting guys, but yeeeessssss. :) :D :)

[SteveA]

Thanks, we will also be able to move our APs to V3 gracefully

Steve.

[butchkemper]

Previously, there were compatiblity issues with some PCMCIA/PCI card adapters and StarOS V1 and V2.

Now that the X86 version is available, I am considering upgrading some of the ATX-733 systems to V3. I would need to use MiniPCI to PCI adapters, so which MiniPCI/PCI adapters are support by V3?

Butch

[i20access]

Will the prism driver support cloaking, or is it an Atheros-only thing?

[lonnie]

The adapter has no active role so it is not an issue with the software. You are concerned only with hardware compatibility and unfortunately we have no current knowledge of those issues.

Previously, there were compatiblity issues with some PCMCIA/PCI card adapters and StarOS V1 and V2.

Now that the X86 version is available, I am considering upgrading some of the ATX-733 systems to V3. I would need to use MiniPCI to PCI adapters, so which MiniPCI/PCI adapters are support by V3?

Butch

[lonnie]

That is Atheros only.

Will the prism driver support cloaking, or is it an Atheros-only thing?

[Beebe]

Ohh yeah baby! Now I can upgrade all my infrastructure overnight and switch from OSPF to OLSR :)

This'll make for a much better upgrade path. Thanks Valemont guys.

[Rick Ashe]

Hi,

Using WRAP for years setting up first WAR at the moment, I have a problem, out of the wrapper neither the WAR 2 or the WAR 4 detected my prism card so I downloaded and flashed them with the newest firmware 1.1.4 build 1509. They still do not see the prism card, I have tried it on its own in minipci1 and along with Atheros cards, it sees the atheros fine but not the prism. I have searched the forum and see a few posts about prism support coming but am not sure if its a case that support hasn't been incorporated yet or there is a problem with the batch of prisms I just bought.

Basically I need to know if prism support is in V3 yet?

[tony]

Prism is supported in the 1.1.5 beta series

[Rick Ashe]

Well that answers that one then!!!!!

Thanks a mill Tony :-)

Rick

[Steve]

I saw that as well. From direct customer feedback I also get the scoop and it seems everybody is having trouble with CB3 whether they are Atheros or Prism based. Our CPE unit will be out in 12 weeks and thus we are moving ahead and find very little motivation to provide backwards compatibility.


Any update on your CPE's?

[lonnie]

Nothing new to report.

[skyclimber]

I posted earlier about N associations. It's the first time i find a real answer . For old CB3 clients I was using a WRAP v2 + SR2 and trying to upgrade to WAR + WML54G.

SOLUTION: The CB3 3054NL were locking to the SSID + mac ID of the AP. Since i'm now using WLM54G i had to re-set the correct mac ID with the SSID.

Client side issue.