802.11 Block Ack troubleshooting

[tomlabaude]

Updated on 05/23/18: @mackenziewifi feedback and final conclusions

Updated on 02/27/18: Anonymized pcap is available here: https://iwaxx.com/downloads/Samsung-80211n-Fail-anonymized.pcap.zip
Anonymized MAC of client is bc:e6:3f:9b:be:d8

Yesterday I've troubleshooted an issue at my client place and my conclusions are not really clear, but it speaks about Implicit Block Ack and Block Ack Requests.
Client looks guilty, but I suspect Avaya AP to be responsible as well.

TL;DR - My findings

• The client systematically never acks packets from the AP (No Ack or Implicit Block Ack)
  All packets from the AP are retried and finally AP sends a Block Ack Req to which the client answers with a Block Ack.
  Then next data packet...
  • Client can receive packets actually: but very slowly 20 packets every 30s ...
• The other direction Client -> AP has no problems
• Why I'm in doubt that it comes from the client only:
  • User never had the problem on another network (simple 802.11n networks are legion)
  • I've already found a tons of bug with Avaya APs ...

Here is the topo

• Client with 200+ Avaya Access Points and 500+ clients
• One single Samsung A5 (a/b/g/n) has this problem currently: can connect but can't browse at all
• Problem entirely systematic and reproductible, only one client affected so far
• The user never had any problem on another network
• Problem happens on 2.4 GHz and 5 GHz
• Disabling 802.11n makes it work
• Can't share the pcap but obfuscated screenshot ok

My technical thoughts

• From my understandings of the 802.11n specs, behavior of the Ack is handled by Ack Policy from QoS Control field.
• I've set a column on Ack Policy, all QoS Data packets from AP are sent with "Normal Ack"
  -> Client should "returns an ACK or QoS +CF-Ack frame after a shortinterframe space (SIFS) period"

ADDBA

Client and AP both agree with ADDBA and Immediate Block Acks (not Delayed)

ADDBA from AP

ADDBA from Client

Examples

First Data Packet, without RTS/CTS

• AP starts with 3x 135Mbps data packets
• AP then lower to 6.5Mbps
• Sends a Block Ack Req
• Client directly acks with Block Ack this SN=0 packet

2nd Data packet with RTS/CTS

After 32s, the 22nd & 23rd packets

Feel free to ask any screenshot, I can't share the pcap unfortunately.
Get in touch on Twitter or by email

This helped me:
http://www.hitchhikersguidetolearning.com/2017/09/17/ht-immediate-block-ack/
http://80211notes.blogspot.fr/2014/04/11n-block-acknowledgement.html

The analysis of @mackenziewifi - Final conclusions

I've had the chance to have the opinion of Peter MacKenzie, CWAP trainer (Certified Wireless Analysis Professional).

"The client does not Ack\BA any frame set at a 802.11n date rate. It responds to the BAR because the BAR is sent at 12 (MBR). I don’t believe this is BlockAck issue. The issue is that the client is not correctly receiving 802.11n packets from the AP."

Then I questioned him again and he explained my principal mistakes during my initial troubleshooting

Client Block Ack Req bitmap is always 0

This means that the client doesn't ack the packet, although there's a Block Ack Req.
This leaded me to a bad conclusion that the client was acknowledging packets, but slowly : in this case, the client didn't ack any packets.

6.5 is an 802.11n data rate - 6 is an 802.11 rate

I argued Peter that the AP lowered to 6.5 Mbps and client still wasn't acknowledging packets thinking it was 802.11 packets.

No, 6.5 Mbps packets are 802.11n.

In fact, client doesn't see any data packets in this trace, all sent using 802.11n standards.
Would another AP react differently and use 802.11 packets instead? Maybe, this would explain that the client would work on other 802.11n networks, but I'd need a packet trace to prove it ;-)

[jhanggj]

Hi @tomlabaude

Did you solve your issue? This is a nice issue thread.

Thank you,
GJ 2018/05/09

[tomlabaude]

Thanks for getting in touch, I just updated the post with @mackenziewifi feedbacks and final conclusions

[ghost]

Hi @tomlabaude

Does your Avaya have a Marvell WiFi chip onboard?
We observe a similar issue on our side.

[tomlabaude]

Avaya APs are OEM of Xirrus & Google seems point on Qualcomm Atheros for chips of Xirrus APs

https://wikidevi.com/wiki/Xirrus_XR-520
https://www.anandtech.com/show/7848/xirrus-to-offer-low-cost-2x2-80211ac-upgradable-enterprise-ap

Anyway, think a 802.11n to 802.11 fallback should not be hardware dependant, but software coded.

[ghost]

Thanks for the info! We experience a 10% to 20% retransmission rate on one of our Marvell-based APs, whereas other makes have literally 0% retransmission rate. For some reason our Samsung phones send regularly an ack asking for the retransmission of a series of packets. The packets' FCS in question are good though (in the trace at least).

Maybe something is broken in your A5? I had a phone once in the lab which was suddenly stuck in a low phy-rate. Identical phones are still working normally to this day.