3 AP's and a lot of dropped packets

  • 1
  • Question
  • Updated 4 years ago
  • Doesn't Need an Answer
We currently have only 3 APs but we're seeing a lot of dropped packets. The AP's are positioned well apart and we've tried lowering the dbm (to prevent overlap) to no effect.

We currently only have about 30 devices spread over the 3 APs. There are a lot of other wireless networks in the area although the signal strength on most is low so we presume they aren't to blame

This system was fine when it was first installed however it seems to have deteriorated and got worse recently. (We haven't changed anything)
Any ideas/advice?

Running: HiveOS 6.1r2.1359
AP's: AP330
Photo of Mattw

Mattw

  • 9 Posts
  • 0 Reply Likes
  • sad

Posted 5 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Others will be able to answer this much better than me, but:

Have you checked for interference with the built-in spectrum analyser?

A laptop watching the air in monitor mode would be a good avenue to observe what is going on in the 802.11 space.

And the obligatory... Are you sure the packet loss is occurring on the wireless side of the network and not the wired?
Photo of Mattw

Mattw

  • 9 Posts
  • 0 Reply Likes
Thanks for the reply.

I'm currently running spectrum analysis and hopefully that'll produce some results. I wasn't actually aware of the feature, I was just using a wifi scanner app on my tablet to find the best channel for each area.

There is some minor packet loss in the wired network but it's very infrequent and rarely noticible unless we're actually running tests.

Matt
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I would also consider disabling the 802.11b data rates if you haven't already done so. It is often best to leave the channel selection up to the APs themselves.
Photo of Mattw

Mattw

  • 9 Posts
  • 0 Reply Likes
Can you explain why I should disable 802.11b data rates? Won't this prevent 802.11b clients from connecting (assuming we still have some)?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
It will prevent 802.11b clients from connecting, but I doubt you have any unless you have a special need / case to support esoteric or broken devices, such as Nintendo's Wii.

With more modern devices, it prohibits them from using data rates that consume a disproportionally high amount of airtime that can impact on other clients - spectrum is a finite, shared, contended resource after all, so using it as efficiently as possible is the name of the game.

See: http://www.networkworld.com/community... and http://www.educause.edu/discuss/netwo...

You can be far more surgical about the data rates that you offer, but this is a good first start.
Photo of Mattw

Mattw

  • 9 Posts
  • 0 Reply Likes
I think I'll go ahead and disable b for now and see if I get any complaints.

Thanks
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Do you also have Dynamic Airtime Scheduling enabled?
Photo of Mattw

Mattw

  • 9 Posts
  • 0 Reply Likes
Yes I've got Dynamic Airtime Scheduling enabled.

I've also just been informed that roaming "never worked".
(There were 2 availible neighbors, 0 selected)

To clarify I wasn't the one who set the system up and I'm not sure how long it's been in place but I've not worked on it until yesterday so please be patient with me.
Photo of Van Jones

Van Jones

  • 75 Posts
  • 4 Reply Likes
Matt, what are you using to observe the dropped packets? Are you pinging from a wireless client to the outside world?

As a point of reference, we are a university with around 12,000 registered student devices. We were having performance issues being reported on the wireless network and Aerohive recommended turning off the lower speeds. So in our SSID profiles, under optional settings / radio and rates / 2.4GHz 11b/g Rate Setting, we set 1 Mbps, 2 Mbps, 5.5 Mbps, 6 Mbps, and 9 Mbps to N/A; 11Mbps is Basic and the remaining rates are optional. This helped us tremendously, but like Nick said it did break the Wii console's ability to connect.
Photo of Mattw

Mattw

  • 9 Posts
  • 0 Reply Likes
I've been pinging from a wireless client to some of our internal servers.

I'll try turning off lower speeds and see if that helps.
Photo of Van Jones

Van Jones

  • 75 Posts
  • 4 Reply Likes
A couple of other things to look at that we have experienced:
1. Do you have consistently high cpu? for us, that's 95-100% cpu over a period of time. You can look at this by connecting to one of the access points via ssh and running the command 'sh cpu detail'. It's ok to see high cpu periodically, but not on an ongoing basis. In one of high cpu cases, I sent a tech data to support and they said that WIPS was causing the high cpu.
2. Reboot one of the access points. Reconnect to that access point and try your pings again. Do you see the same drops? One of the things that we are seeing is that cpu will get really high, but a reboot will take care of the issue for a period of time (with all other variables that we can observe being the same).
3. Are there any errors on the switch port that the access point is plugged into (or on the uplink port of the switch)?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Yup! As others have said, it would be fantastic to see MIB support in this area... The interesting thing about the WIPS issue is that a scheduling issue is likely to exist in HiveOS. There's nothing wrong with 100% CPU usage where only lower priority background tasks are impacted...
Photo of Mattw

Mattw

  • 9 Posts
  • 0 Reply Likes
#1: On the APs we get occasional spikes of CPU to approx 95% but quite rarely. Generally they run below 20%.

#2. I've tried this but it only seems to last for a few minutes before the drops start again. Also the APs seem to take ages to reboot.

#3. Not that I'm aware of. The same switch is used for most of the ethernet routing for the office PC's and they don't drop pings.
Photo of Scott Webb

Scott Webb

  • 3 Posts
  • 0 Reply Likes
Mattw,

I recently had a problem with a site where wireless was have a lot of dropped packets, at least when I was ping testing, and the response times were high. I found that the 3 IP cameras that were on the network were using a lot of multicast traffic. The fix for me (I was not able to VLAN at the time at this site), was to tell the AP to always convert all multicast traffic to unicast traffic. This is done in the SSID profile(s). This brought down my CPU and memory usage to acceptable levels.

Just a thought.
Photo of Mattw

Mattw

  • 9 Posts
  • 0 Reply Likes
I don't think the CPU/Memory is a problem here.

We only have 3AP's with a maximum of about 16 devices connected to each at any one time.
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
On the three access points what are the transmit and receive error counts?
Photo of Mattw

Mattw

  • 9 Posts
  • 0 Reply Likes
AP1: Rx packets= 45486040; errors=0; dropped=397959;
Tx packets=129217670; errors=28924; dropped=     0;

AP2: Rx packets=32458669; errors=0; dropped=678957;
Tx packets=30765874; errors=1375683; dropped=   393;

AP3: Rx packets=18177435; errors=0; dropped=161319;
Tx packets=13157625; errors=697971; dropped=     0;