cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
15031
Views
10
Helpful
70
Replies

WAP371 Slooooow

Hello,

I just got an WAP371 yesterday. I am using the SB-PWR-INJ2 to power it over PoE. I updated the firmware to the latest version 1.0.1.5. I am experiencing terribly slow performance with the device. It is supposed to be replacing a N450 access point. With the N450 AP I have no troubles getting about 20MBps (160mbps) over wireless when in line-of-sight of the AP. With this new AP, even though the signal is strong, the RSSI is good and the transmit rate is good, I am experiancing horribly slow connectivity rates. On AC wireless connected to a MacBook Air I have not passed 25mbps (3.1MBps) even thought the Air is connecting to the AP just fine with acceptable levels. What gives here? I was expecting at least  50% increase in performance with AC clients, not a 80% decrease! 

Any ideas what to do?

Screen shot is attached. 

70 Replies 70

ofwegen
Level 1
Level 1

Are u using vlans? I had horrible speeds as well. I started troubleshooting and found out that SSID's that did not use tagging/untagging were pretty fast (200 Mbit). When I tested with SSID's that did tagging, it was horrible (20 Mbit). I've reported the issue to Cisco, and they acknowledged the problem. I've received a beta firmware which solved this issue. When a general release will be available is yet unknown. As a workarround I setup my guest wifi as tagged (=slow) and production as untagged within the same network as the ap ip interface untagged (=fast). I've noticed some other issue's with the management interface losing it's default gateway but I've stopped hunting bugs since the support engineer did not even understand the basics of networking, and I normally get paid to fix network issue's. :-)

I have the exact same problem(s). Hope the release a new firmware soon that fixes this problem. 

I am using VLANs. Everything is using tagged VLANs since that is the design of the network. It's required since there are multiple SSIDs being used going to differnt VLANs. I suppose the network with the greatest traffic could be changed to be the untagged VLAN, but that is not ideal and needs resolved. 

Do you know of a way to get this beta firmware for the AP? Hoping a new version will be out soon. 

I had to change my design as well to get acceptable speeds. I don't understand that such a basic thing as using vlan's is causing this, such a thing should have been tested prior to releasing a new product.

The issue is reported under SR631797383, maybe you can try to obtain the beta fw as well. The issue is known and acknowledged by Cisco since 11-09-2014, that more than 2 months ago. :-(

Be aware that the beta fw contains issue's as well. Some clients are losing their connectivity to the wlan and don't seem to get connected anymore (until a power cycle of the ap).

Besides that, there is still the issue (also in current latest fw) that the ap might lose it's default gateway on the mgnt interface.

I have the same problem. I get 1.5 Mb/s on a tagged VLAN but full speed on the untagged VLAN.

Moved my response so that I replied to the correct post.

Eric

Same problem with VLAN configuration.
I received last week a WAP371 (FW 1.0.1.5) and have the same problem. Will contact the Cisco Support and the Reseller. But some beta version firmware is not a Reputable solution for me and a Network redesign even less.
Thanks for the info here ...

Regards

My name Eric Moyers. I am an Engineer in the Small Business Support Center.

I am sorry to hear that you are experiencing this issue. 

As was stated in parts of this thread, this is an issue that we have acknowledged and have a solution for.

Unfortunately it has not cleared all of our testing as of yet, but we have a beta version available of those customers that are needing this particular issue resolved now. The beta version does include the fix for this issue, however it has not passed testing to ensure our fix did not create an issue somewhere else.

I can understand the hesitation of going with a beta version, that is not a step to be taken lightly. If at all possible Cisco prefers that customers wait for a good steady release, but for those that can't has the beta available.

In order to ask for a beta firmware for this device or any other, please call in to the Small Business Support Center and have a case created. In general, there will be some troubleshooting to ensure that the beta will correct your issue and then we can get you escalated to the group that controls the beta so that they can get you setup.

Eric Moyers
.:|:.:|:. CISCO | Cisco Technical Support | Wireless and Surveillance Subject Matter Expert

Please rate helpful Posts and Let others know when your Question has been answered.

Hi Eric,

 

Thanks for your reply. It has almost been 3 months since Cisco was made aware of this problem. It's not a small typo in some help page. Is a basic element of networking which will make/brake a design. The product was brought onto the market to fast. If testing was really that intensive (3 months!) the bug would never have been in the product to begin with. It's just a matter of priorities. Imagine you buy a sedan car and can only use the driver seat, or accept a speed limit of 30 mph with multiple people in the car..... We wouldn't even be discussing the issue.

 

Leon 

Yes Sir I can understand your frustration.  Having a car and being limited to 30 miles an hour, when you have passengers is unacceptable, and should be fixed. 

Having slow performance when you tag a vlan is not acceptable and we have fixed it. 

  • The issue was acknowledged on 09/19/2014.
  • From that date we had to first discover what was the exact problem that was causing the issue. (with code that is not an over night process). 
  • We were able to accomplish that in a few days and then we had to re-code the current firmware with the new changes. The beta version was created on 10/12/2014 and made available for limited customers on 10/23/2014.
  • It took us three weeks to find the issue, come up with a solution and re-coded. Pretty good timing I think. Using this timing I don’t think many companies can accept, investigate and provide a solution any quicker.

Using your great example of the car, Car companies will sometimes take years to agree that there is an issue and even at that point resist that they need to do anything to correct the perceived problem.

Read more: http://www.bankrate.com/finance/auto/the-8-most-infamous-car-recalls-in-history-1.aspx#ixzz3LKMvR6cE 

While I realize that this is an extreme, none the less, mistakes get made when designing anything. The optimal outcome is that quality testing catches everything and your product goes without a hitch and there is never a need to do anything ever again. 

Unfortunately, things are designed and built by humans. What shows a true company that cares about its customers, is that they react to issues and strive to correct problems.

I truly appreciate you buying Cisco products and I am truly sorry for the current issue that you are facing. I know that we have worked hard to get a solution available as quickly as we did. As soon as we can confirm that this solution has not impacted any other part of the code, we will make it available for general release.

If I can be of any assistance with any wireless or other issue, I am always available. If you prefer, you or anyone can always reach me by email. (Mouse over my picture and you should find my email address)

Eric Moyers

.:|:.:|:. CISCO | Cisco Technical Support | Wireless & Surveillance Subject Matter Expert

Please rate helpful Posts and Let others know when your Question has been answered.

    Your dates are not accurate. The problem was confirmed to me on 11-09-2014. I've received the beta firmware on 14-10-2014. But that's details. I don't complain about the speed that I received the beta firmware, I know that generating/fixed code takes time. But from beta to general deployement release in two+ months is quite a long time. Why not release a minor update to the current release with just the vlan stuff fixed? All the other bugs/functionality can still go through the normal process.

    Don't get me wrong, I don't blame anyone for having a mistake in a product. It bothers me that such an basic part of the device is not working. If there was a bug in the ntp daemon or syslog functionality I'd say, we can live without it for now, but it would be nice to have it fixed. But that's not the case, there is a serious problem with the device which brakes designs and forces people/businesses to run beta firmware. 

    We may have a slight misunderstanding when I say 09/19/2014 and 10/23/2014, I mean Sept 19 2014 and Oct 23 2014. I am assuming that your dates are meant as Sept 11 2014 and Oct 14 2014.

    On Sept 12 2014 the bug was discovered with your case and on Sept 19 it was entered into our logging as a confirmed bug. After initial testing Oct 12 2014 the beta was given to you Oct 14 2014.

    At this point we have a working fix. Not being in that department, but having done Mainframe coding in a prior job. I can only surmise that they are now trying to avoid bringing something to market too fast, as you stated earlier. 

    I agree it was a serious issue and it is now working and available.   

    Eric Moyers

    Hi Eric

    Thanks for the reply. I had already contact the Cisco Small Business Support. OK, I will probably request the beta firmware. Is there perhaps a reference to this issue in order to speed up the process. (because the lady from the support did not know this Issue)

    Thanks and regards

    Thomas

    The issue was reported under SR631797383. Maybe they can find it under that service request?