Wireless Access

Ok banging my head against a wall a little with this one. I am debugging a voice call with a CDR (and handset) reporting high % of lost packets and noticed something in the capture.

 

Basically there are many voice data frames from AP to client but there are no ACKs for these. The capture is 20,000 frames and there are actually ZERO ACKs with receiver address of the client. Everny single ACK has receiver address of the AP. If there are even some ACKs going missing shouldn't I at least see some retries from the AP to Client? Again ZERO retries in that direction. These two factoids seem to contradict each other.

 

Conversevely there are plenty of ACKs captured from AP to client, and I do see some retries from Client to AP.

 

I am a little suspicious that the capture is not complete, but no filtering was enabled. How reliable is an AP packet capture generally?

 

I will upload the capture in the general hope some kind soul may be able to see something I can't :)

 

 

 

Your packet captures generates a ton of questions.

- What kind of voice client?
- Is there encryption being used?
- What access point is being used?
- What method are you using to capture packets?
 
 

- What kind of voice client? Spectralink 84 series
- Is there encryption being used? WPA2-PSK
- What access point is being used? AP-135
- What method are you using to capture packets? AP Capture, i.e. forwarding over UDP port 5555 to a laptop

Did you follow the configuration recommendations of the roaming VRD here: http://www.arubanetworks.com/wp-content/uploads/DG_Roaming.pdf

It has configuration parameters for spectralink phones...

Well, thanks will check it out. I didn't build it, just troubleshooting. I did look at the Aruba-Spectralink VIEW whitepaper and config looks ok.

 

But my question is quite particular to the capture. I don't see any ACKs from the client. So I should see retransmits from the AP, but I don't see those either. 

 

 

You didn't say what Mac address is that of the client.
You also did not say if you are running 20 MHz channels and what band you are running the traffic.

NOTE: if the access point you are using to do the captures is the one serving your client, you might not be able to see all packets from that access point to the client...

So the phones are configured for 2.4GHz only (not ideal). 

 

There's 2 calls in the capture and they're from the same device..

 

00:90:7a:12:0b:c2  (10.51.41.43)

 

The AP is 9c:1c:12:ac:4b:20 and the default gateway for the phone is c2:ea:e4:82:44:46

 

First call starts around packet 130. Subjectively we heard dropouts and phone and controller CDR reported 15% dropped packets on the call, and this matched up with retried wireless packets on the phone diagnostics.

 

Second is around packet 13600. This had 33% loss recorded, again numbers matched up. But very puzzling no retries in the "to phone" direction.

 

BGC IT,

 

It is not clear what is wrong in the big picture here; there is simply not enough information.  The problem could occur on many levels that are not obvious.  In the SSID profile for WLAN under advanced, please enable "Advertise QBSS Load IE" and do the capture again so TAC can see the load on the WLAN in the management frames on the access point:

http://www.arubanetworks.com/techdocs/ArubaOS_64_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/VirtualAPs/SSID_Profiles.htm?Highlight=Advertise QBSS Load IE

 

Also, try to do a packet capture with an external device  of the entire channel (air monitor or laptop with packet capture software); NOT the access point that is servicing the client, so that we can ensure that all traffic is captured.

 

The packet capture is only part of the picture.  It is best that you open up a case with support in parallel so that they can gather all of the information and understand what factor(s) could be leading to your issue.  If there is intererence for example, we could not tell by just a packet capture.  Unless we have the logs.tar and the tech-support from the access point when this call takes place, we do not have a logical starting point.  This could be a phone software/configuration issue, an interference issue, an Aruba controller configuration issue, or a wired traffic issue, etc.  VOIP is the most difficult type of traffic to troubleshoot and it is painful to pass pieces of data back and forth without having all the info at hand to understand what is going wrong.

 

Ok thanks, I'll take the advice and go the TAC route and repeat the capture in the air.