Controllerless Networks

I'm seeing this issue with a client who is using the latest Microsoft SurfaceBook Pro (Marvell Avastar AC) with Aruba IAP515. The client is seeing very poor performance in streaming applications to their projector using AirTame.
On other devices (tested with Macbook, MBP, Lenovo Yoga X1) and they're buttery smooth.
On the Microsoft device, we often lose video performance and lose audio altogether.
 
In a promiscious packet capture, we're seeing repeated block acks for the same sequence number... In one of the packet captures, we had 524ms there’s just block ack requests from the Surface Book 2 for SSN 1319, and block acks for SSN 1319 from the Aruba 515 ( see screenshot below)

 
Also, we have experienced wireless performance decline : Surface with Aruba APs For some reason, APs send BAs with Block Ack Bitmap all zeroed against BARs and Data Frames received from Surface.
 
Any thoughts on the above?

The case has been raised with Aruba TAC already and now looking into the issue:

HPE Support Case 5340132091

Another issue - but still related to Block acks

 

We've just taken three traces on the IT Director's Surface Book 2. 

 

The wireless symbol was still active showing connectivity, but ping times were well in excess of 1000ms. A wifi capture and downloaded the Surface wifi trace command. We saw lots of repeated block ack requests from the AP, and also the Surface sending block acks with 00:00:00:00:00:00 destination. fast.com reported 360kbps. Web access was possible but very slow. I didn't bother trying Airtame during this time. I took another trace but it wasn't great since it took forever to start, so there's a wifi off/on that may or may not be captured, and also some roaming between APs to see performance on different APs​ - Aruba Central reported bad client health. I also saw some extremely low rates from `netsh wlan​ show int` like 13mbps when I was under 5 metres from the AP with line of sight.

 

I then started a new capture and turned WiFi off and on, still had the problem, then disabled/enabled the device and that fixed it. Although in the subsequent fast.com speed test which reported 200Mbps download and 220Mbps upload (the Aruba 515s are configured with 40MHz channels), the upload still had a significant number of retransmissions.

 

 

How are your access points mounted? (how high and how are they positioned)

How far away was the client during these tests?

Are you using encryption?

If you are capturing frames on that channel(s) are the retries limited to that client or are they on the whole channel?

 

Thanks Cjoseph. Answers are below:

How are your access points mounted? (how high and how are they positioned)
- they're all mounted on the ceiling height (about 3-4m). This is done across two floors and staggered between floors.

How far away was the client during these tests?
- during these tests, we were about 6 metres away from the nearest AP

Are you using encryption?
Yes

If you are capturing frames on that channel(s) are the retries limited to that client or are they on the whole channel?
- Retries are limited to that client only

Ok.

Have you tried only using 20 MHz channels on the 5ghz and retesting?

Yes. We have tried that.
We have also tried putting it in Legacy mode and the Block acks no longer appear.

It's such a frustrating problem.

Hi Davevo,

I looked at the screen shoot of capture you attached in the other thread, the BlockAckReq does indeed flood the air so for sure everybody is impacted in that channel.

I also see BlockAckReq does indeed use TID4 which is for AC_VIDEO.

This sound like a driver issue from the Marvell driver.

I hate to ask but do you know if there is a later version of the driver?

Usually there is a limit on the # of BlockAckReq sent, normally after some retries let say 10, the sender is supposed to increase the sequence# by 1 to move the blockack window.

In the past, I had to disable LDPC on Marvell chipset, I hope they had fixed the issue.

The fact that you put Legacy Mode, there is no link aggregation so no BlockAck, but for sure you are not using the full power of your new 802.11ax toy 8--)

 

H_Matrix

Thanks for your reply H_Matrix.

Yes, it would be flooding that channel. I misunderstood the question, the capture was taken on the channel that the client was on. The client was the only device on the network at the time.. (it's school holidays at the moment)

We've tested with both latest drivers for Windows 10 1809 (ending in 9125.57) and Windows 10 1903 (ending in 9127.59). Both exhibits same problems.

I was planning to turn on "max-tx-fails" to then kick the client after a number failed transmit retries. But it seems you cant do this under Virtual Controller.. so considering converting to VMC.
Also, I believe that with a Controller, you can disable LDPC, once again, not available under Virtual Controller - unless I've missed something?

How did you disable LDPC on the Marvell chipset?

You can either disable LDPC on the client if that option exists when you go into the wifi adapter configuration, or you can disable it on the AP side to adversite you do not support LDPC, so client will not use LDPC coding for transmit.

 

Or you can go into window registry where the config of the adaptor is stored, there are much more config there not exposed to the GUI.

 

From your screen capture where the AP does BlockAck, I see the TID is 0, not the same as the BlockAckReq from the client where TID=4, I assume both screen shot are from the same capture.

 

If that is the case, than the bug is on the AP side where it responded with TID=0 instead of TID=4(from client), so if client driver is not forgiving, it will keep resend BlockAckReq with TID=4 forever like you see.

 

Anyhow, it is fun to troubleshoot your problem 8-)

 

H_Matrix

Haha I wish I had your optimism. I love these problems, only when you have a resolution. 🤣

I couldn't find anything on the client side to disable LDPC. Definitely not within the drivers hardware settings.

You mentioned registry? Any pointers where that may be?

I'll need to check the screenshots and TID.

Hi Davevo,

 

I attached a registry screenshoot of my intel driver just to give you an idea where all the parameters are stored.

I try to get the same screen from the Surface laptop 2 my nephew just got but was not able to yet.

Just to tell you we were able to do 4K Youtube streaming at 127M no issue on the Surface, at my nephew home they have fiber to the home and the router is the BellHub3000 (Quantena chip for 5G).  On speedtest.net we get 240M DL and little bit less in UL, quite amazing as the router is in the basement and we ran the test on first floor.

 

Setting this to 0 means the client tells the AP it does not support to receive LDPC, however it can still send LDPC to AP if AP advertises it can, so you need to figure a way to disable it on AP so both direction are non-LDPC, you can see in beacon if LDPC is enabled or not.

Thanks H_Matrix.

 

I tried looking at my laptop and it doesn't appear there (mine is an Intel AC 8265).

 

Not sure if this will appear in the Marvell driver set either...

 

 

Hi Davidvo,

intel 8265 is a AC card so they probably keep that TxLdpc hidden, my card is 8260 and I do have TxLdpc shows up in registry.

If you are gunho, you can create the missing key by creating a DWORD32 key of TxLdpc in the location of your card registry setting and set the value to 0, then Disable follow by Enable your wifi card in the control panel (to have the driver restart to re-read the config).

On my card I have the key HtRxLdpc set to 1, this is to tell AP we can receive LDPC, you can create key is not present and set to 0, so no LDPC on TX and RX.

 

To uncover some hidden keys, you can use strings tool from sysinternal suite to extract meaningful strings inside the driver, like I say you have to be a bit gunho 8-)

 

My 8250 does not have MU-MIMO where as the 8265 has.

 

Let me see from my nephew Surface.

 

H_Matrix

Tried all the above... come to the conclusion that nothing can be done to hide or overcome the issues....

 

Very frustrating.

davevo,

Have you found a fix for this issue? I believe we are seeing similar problems with Surface devices and IAP 515s.