WILINK8-WIFI-MCP8: WiLink8 Block-ACK issue with Samsung Galaxy S7 tablet (Qualcomm®︎ FastConnect™︎ 6x00)

Hi Andy,

If you could provide the .pcap files, I can look them over. 

Could you please further explain your application and hardware setup? Is the WL8 connected to a linux based MPU? If so, what is the linux kernel version?  

The application is a dedicated device which the tablet is interacting with to sync/share data.  It is running 2.4GHz only and acting as the Access Point.  I would rather not post pcaps to a public site, is there another way to get them to you?

The WL8 is connected to a Linux based system running kernel version 4.19.94 and has an AM3358 processor.

Hi Andy,

Have you applied the R8.8 kernel driver patches? You can find a guide on how to apply them here: https://www.ti.com/lit/swru561  

While we are working on verifying that each kernel and hostap patch is in our system, it is my understanding that the firmware owns the content for the Block-ACK bitmask.  Is it possible for TI to confirm that the WL8 can support talking to devices as an AP where those STA devices are using different Sequence Number chains for different QoS packet types?

Hi Andy,

I've started a direct messaging conversation with you so that we may share any files back and forth. I will look over the logs that you send over and update you early next week. 

Hi Andy, 

I would like to start reproducing your issue. But to confirm that I do see the issue, I would really like to have the pcaps you captured. Please let me know if you are unable to find E2E's direct messaging system. We can use that to share files. 

Furthermore, if you are able to collect firmware logs via gLogger, that would be helpful as well. 

The direct messaging system doesn't appear to let me attach pcap files.  I was able to attach the Excel chart that shows the different QoS Data and QoS NULL sequence number streams as well as the last good block-ACK'd sequence number (attached here for others reference).  It appears to show that the WiLink 8 Block-ACK jumps back and forth between the two different sequence number streams when they get "too close"

Hi Andy,

Thank you for providing the .pcaps. The graph also helped me see the "switching", I believe I see what you are describing. The behavior is certainly strange, and we will need to debug this further. I'm not sure 

I'll need to replicate the issue on my side so that we can continue debugging, but I'll need some assistance here. Could you please provide (either publicly or privately) the hostapd.conf and any other relevant configurations (changes to INI, etc.)? What was being run on the application layer, or is there anything similar that I could use to recreate the issue? 

I've uploaded the hostapd.conf file to the drive directory you sent.  We haven't made any changes to the .ini files used by configure-device.sh.  The .ini file used is: https://git.ti.com/cgit/wilink8-wlan/18xx-ti-utils/tree/wlconf/official_inis/WL1835MOD_INI_C2PC.ini.

Here's the output of that script:

TI Module: y
Chip Flavor: 1835
Base INI file used: /usr/sbin/wlconf/official_inis/WL1835MOD_INI_C2PC.ini
Number of 2.4GHz Antennas Fitted: 1
Number of 5GHz Antennas Fitted: 0
Diversity Support: n
SISO40 Support: y
Japanese Standards Applied: n

The version of that file used was: git.ti.com/.../WL1835MOD_INI_C2PC.ini

Hi Andy,

Which access category (ac) are you using? If you switch to another (voice, video, etc.) does the issue persist? 

Furthermore, since the issue only seems to occur on this android tablet, could you please provide us with other methods to reproduce this issue? We don't have this tablet at this moment. 

We aren't setting any AC values on the traffic we are sending from either side.  The sniffer capture confirms that.  The reason that WMM matters is that without WMM you don't get the Block-ACK feature which is at the root of this issue.  If we turn off WMM the problem will go away (because we stop using Block-ACK), but results in 30% less performance.

The only way you will be able to reproduce this issue is if the device connecting to your WL8 AP is sending type 0x002c frames (QoS NULL).  Any of the Galaxy S7 tablets or anything else using the Qualcomm FastConnect 6x00 Wi-Fi implementations should trigger the same problem.

[Edit], adding example of QoS Control on the QoS Data frames sent by the tablet:

We ran a test where the Android side placed a Video classification on the TCP traffic and no issues with that communications path were encountered.  This is not a complete solution because it does not apply to ARP, DHCP, mDNS, or other non-TCP services but it does give us a clue that the WiLink8 side appears to have a Block-ACK state machine that is tied to classifications.

Thanks for this additional insight, it is something that we will investigate further. In the meantime, we are working on acquiring a device with that qualcomm chipset. 

It's worth noting that we ran the same test against a legacy device using the WiLink6 and did not experience the issue.  WMM and 802.11n were enabled and Block-ACKs were flowing in both directions.  The big difference was that the WL6 was using the standard ACK (type 0x001d) for the QoS NULL frames sent by the tablet, whereas the WiLink8 is using Block-ACK to ACK the QoS NULL frames.

Hi Andy, Please see your direct messages for an important update.