CC3301: The WiFi firmware occasionally drops packets, causing the TCP transmission speed to drop to 0(R6 version)

Hi Yuan,

Can you explain the setup here? Which CC33xx SDK are you using? Is CC33xx the iperf3 server or client? Is it in AP mode or connected to an external AP?

R6 SDK we used.  CC33xx is in station mode. our customer report this issue, and they run iperf3 in CC33xx as server. 

In my test, I run iperf3 in CC33xx as client, sometimes I also can reproduce this issue.

Hi Yuan,

Okay. Just for my understanding, did you implement the iperf on top of R6 SDK or did you use any particular example? Could you provide example method for us to reproduce?

Hi Sabeeh

We did not test this issue directly with the R6 SDK. Instead, we ported the Wi-Fi driver from the R6 SDK to our RTOS platform, which uses the SDIO interface. We ran iperf3 on our platform using the Wi-Fi driver from the R6 SDK to test this issue. Perhaps you could reproduce this issue on your platform with R6 sdk, or we can provide the test data to you.

Hi Yuan,

We have many fixes in our firmware that should address issues like this. However they have not yet been updated within the ThickMAC solution. Let me see what I can do on my side and I will report back soon. 

Hi Sabeeh

Is there any update? Our customer is very anxious about this issue.

Hi Sabeeh

We have discovered a method that seems can fix this issue. The method is changing power-saving mode of the WiFi chip. Originally set to 'auto', changing it to 'active' appears to make the problem disappear. Therefore, is the power-saving mode the root cause of this issue? Could the 'auto' mode have such a significant impact on TCP traffic? What potential issues might arise from switching to 'active' mode?

Hi Yuan,

We don't have a iperf3 implemented on R6 SDK, so I'm unable to replicate this issue. Would you be willing to provide your implementation of iperf3 so that I can run in on my hardware? I can then better reproduce the issue.

There is no issue with using active power mode, the device will instead may have a higher power consumption. The issue could be related to using power save mode, but we will need to investigate this further to confirm. 

Hi Sabeeh

iperf3 is not necessary, iperf also can do this test.
 In our further testing, setting the power save mode to active can only mitigate this issue. If the device maintains the connection and there is no data transmission for a while, the next time data transmission starts, the rate will still drop to 0. Another problem is that both WLAN_SET_POWER_SAVE and WLAN_SET_POWER_MANAGEMENT are used to configure power save mode. What is the difference between these two parameters, and how should they be set to ensure that the Wi-Fi remains in active mode continuously?

Hi Yuan,

WLAN_SET_POWER_SAVE is the command you are interested in. There is 802.11 Power Save, which means that the CC33xx device is telling the AP that is going in and out of power save. You can think of this power save as limited to the RF system.

The WLAN_SET_POWER_MANAGEMENT controls the power activity of the entire CC33xx device and has no relation to the link with the AP. 

From the information you have provided about this issue, I believe that you would need to set "WLAN_SET_POWER_SAVE" to "WLAN_STATION_ACTIVE_MODE". 

Hi Sabeeh

Regarding the parameter "WLAN_SET_POWER_MANAGEMENT," which setting do you recommend?

Hi Yuan,

I would not recommend changing this parameter as the firmware should boot with default parameter of ELP mode. Only change "WLAN_SET_POWER_SAVE". 

When WLAN_SET_POWER_SAVE is set to auto, this issue occurs. Does this indicate that the auto mode has a bug? Does the FW need to fix this issue?

Hi Yuan,

Yes it does sound like a bug, but we have addressed many issues in the firmware, we would need the firmware to be updated in the SDK release and then test again.

However, we can try to understand the bug as it is. Would you be able to collect FW logs from the LOGGER pin? I can then review with the team and see if this issue has already been addressed internally. 

Yuan,

whenever you can please provide us with the information requested by Sabeeh.

In addition I have sent youand your team an engineering FW that should improve or fix the behavior.

It is critical to get logs if we want to understand the issue and fix it.

Hi, 
This Fw log file, pletcp_throughput.pcapng.txtase check it.

Server [192.168.31.154] listening on [5201]
-----------------------------------------------------------
Accepted connection from 192.168.31.93, port 56008
[  5] local 192.168.31.154 port 5201 connected to 192.168.31.93 port 56009
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  154 KBytes  1.26 Mbits/sec                  
[  5]   1.00-2.00   sec  1.50 MBytes  12.6 Mbits/sec                  
[  5]   2.00-3.00   sec  93.8 KBytes  768 Kbits/sec                  
[  5]   3.00-4.08   sec  115 KBytes  874 Kbits/sec                  
[  5]   4.08-5.00   sec  1.33 MBytes  12.1 Mbits/sec                  
[  5]   5.00-6.00   sec  1.17 MBytes  9.83 Mbits/sec                  
[  5]   6.00-7.00   sec  603 KBytes  4.94 Mbits/sec                  
[  5]   7.00-8.06   sec  56.9 KBytes  440 Kbits/sec                  
[  5]   8.06-9.00   sec  769 KBytes  6.70 Mbits/sec                  
[  5]   9.00-10.00  sec  148 KBytes  1.21 Mbits/sec                  
[  5]  10.00-11.00  sec  778 KBytes  6.37 Mbits/sec                  
[  5]  11.00-12.46  sec  681 KBytes  3.82 Mbits/sec                  
[  5]  12.46-13.00  sec  754 KBytes  11.4 Mbits/sec                  
[  5]  13.00-14.00  sec  813 KBytes  6.67 Mbits/sec                  
wlan    [  5]  14.00-15.00  sec  388 KBytes  3.18 Mbits/sec                  
[  5]  15.00-16.17  sec  1.25 MBytes  8.96 Mbits/sec                  
[  5]  16.17-17.00  sec  863 KBytes  8.52 Mbits/sec                  


******************************************************************
*****************   Version 1.1.0.4            *******************
******************************************************************
================================================================================
Available commands:

help                clear               scan                get_mac             
set_mac             get_ps              set_ps              set_pm              
set_LSI             calibrator          
================================================================================

# 
wl[  5]  17.00-18.00  sec  93.8 KBytes  769 Kbits/sec                  
an get[  5]  18.00-19.65  sec  601 KBytes  2.99 Mbits/sec                  
_[  5]  19.65-20.00  sec  537 KBytes  12.6 Mbits/sec                  
ps

[PS MODE] current PS mode is Auto Power save

# 
[  5]  20.00-21.00  sec  154 KBytes  1.26 Mbits/sec                  
[  5]  21.00-22.03  sec  35.5 KBytes  283 Kbits/sec                  
[  5]  22.03-23.07  sec  41.2 KBytes  325 Kbits/sec                  
[  5]  23.07-24.00  sec  1.53 MBytes  13.8 Mbits/sec                  
[  5]  24.00-25.27  sec  448 KBytes  2.89 Mbits/sec                  
[  5]  25.27-26.00  sec  1.05 MBytes  12.0 Mbits/sec                  
[  5]  26.00-27.00  sec  1.00 MBytes  8.41 Mbits/sec                  
[  5]  27.00-28.00  sec  1.21 MBytes  10.1 Mbits/sec                  
[  5]  28.00-29.00  sec  64.0 KBytes  524 Kbits/sec                  
[  5]  29.00-30.00  sec  1.66 MBytes  13.9 Mbits/sec                  
[  5]  30.00-31.00  sec  1.14 MBytes  9.57 Mbits/sec                  
[  5]  31.00-32.00  sec  1.45 MBytes  12.1 Mbits/sec                  
[  5]  32.00-33.00  sec  1.48 MBytes  12.4 Mbits/sec                  
[  5]  33.00-34.00  sec  1.14 MBytes  9.60 Mbits/sec                  
[  5]  34.00-35.00  sec  1.55 MBytes  13.0 Mbits/sec                  
[  5]  35.00-36.00  sec  1.38 MBytes  11.6 Mbits/sec                  
[  5]  36.00-37.16  sec  154 KBytes  1.08 Mbits/sec                  
[  5]  37.16-38.00  sec  600 KBytes  5.85 Mbits/sec                  
[  5]  38.00-39.00  sec  614 KBytes  5.03 Mbits/sec                  
[  5]  39.00-40.00  sec  1.06 MBytes  8.93 Mbits/sec                  
[  5]  40.00-41.12  sec  117 KBytes  853 Kbits/sec                  
[  5]  41.12-42.00  sec  1.34 MBytes  12.7 Mbits/sec                  
[  5]  42.00-43.00  sec  748 KBytes  6.13 Mbits/sec                  
[  5]  43.00-44.49  sec  732 KBytes  4.03 Mbits/sec                  
[  5]  44.49-45.53  sec  49.8 KBytes  392 Kbits/sec                  
[  5]  45.53-46.00  sec  771 KBytes  13.4 Mbits/sec                  
[  5]  46.00-47.00  sec  1.65 MBytes  13.8 Mbits/sec                  
[  5]  47.00-48.69  sec  747 KBytes  3.62 Mbits/sec                  
[  5]  48.69-49.00  sec  337 KBytes  8.89 Mbits/sec                  
[  5]  49.00-50.00  sec  678 KBytes  5.56 Mbits/sec                  
[  5]  50.00-51.00  sec  510 KBytes  4.18 Mbits/sec                  
[  5]  51.00-52.69  sec  195 KBytes  944 Kbits/sec                  
[  5]  52.69-53.00  sec  193 KBytes  5.11 Mbits/sec                  
[  5]  53.00-54.71  sec  193 KBytes  926 Kbits/sec                  
[  5]  54.71-55.00  sec  24.2 KBytes  683 Kbits/sec                  
[  5]  55.00-56.00  sec  512 KBytes  4.19 Mbits/sec                  
[  5]  56.00-57.00  sec  2.84 KBytes  23.3 Kbits/sec                  
[  5]  57.00-58.00  sec  408 KBytes  3.34 Mbits/sec                  
[  5]  58.00-59.00  sec  65.4 KBytes  536 Kbits/sec                  
[  5]  59.00-60.00  sec  230 KBytes  1.89 Mbits/sec                  
[  5]  60.00-61.00  sec  11.4 KBytes  93.2 Kbits/sec                  
[  5]  61.00-62.00  sec  11.4 KBytes  93.2 Kbits/sec                  
[  5]  62.00-63.00  sec  549 KBytes  4.50 Mbits/sec                  
[  5]  63.00-64.00  sec  975 KBytes  7.99 Mbits/sec                  
[  5]  64.00-65.00  sec  62.6 KBytes  513 Kbits/sec                  
[  5]  65.00-66.00  sec  313 KBytes  2.56 Mbits/sec                  
[  5]  66.00-67.00  sec  808 KBytes  6.61 Mbits/sec                  
[  5]  67.00-68.07  sec  101 KBytes  773 Kbits/sec                  
[  5]  68.07-69.00  sec  1.44 MBytes  13.0 Mbits/sec                  
[  5]  69.00-70.00  sec  1.46 MBytes  12.2 Mbits/sec                  
[  5]  70.00-71.00  sec  1.74 MBytes  14.6 Mbits/sec                  
[  5]  71.00-72.63  sec  963 KBytes  4.84 Mbits/sec                  
[  5]  72.63-73.68  sec  72.5 KBytes  566 Kbits/sec                  
[  5]  73.68-74.00  sec  523 KBytes  13.4 Mbits/sec                  
[  5]  74.00-75.00  sec  1.08 MBytes  9.09 Mbits/sec                  
[  5]  75.00-76.12  sec  156 KBytes  1.14 Mbits/sec                  
[  5]  76.12-77.00  sec  1.26 MBytes  12.0 Mbits/sec                  
[  5]  77.00-78.03  sec  56.9 KBytes  453 Kbits/sec                  
[  5]  78.03-79.00  sec  1.16 MBytes  10.1 Mbits/sec                  
[  5]  79.00-80.00  sec  225 KBytes  1.84 Mbits/sec                  
[  5]  80.00-81.65  sec  1.14 MBytes  5.80 Mbits/sec                  
[  5]  81.65-82.00  sec  562 KBytes  13.1 Mbits/sec                  
[  5]  82.00-83.00  sec  1.62 MBytes  13.6 Mbits/sec                  
[  5]  83.00-84.00  sec  1.71 MBytes  14.4 Mbits/sec                  
[  5]  84.00-85.64  sec  1.21 MBytes  6.17 Mbits/sec                  
[  5]  85.64-86.00  sec  306 KBytes  6.96 Mbits/sec                  
[  5]  86.00-87.51  sec  439 KBytes  2.38 Mbits/sec                  
[  5]  87.51-88.00  sec  816 KBytes  13.6 Mbits/sec                  
[  5]  88.00-89.00  sec  1.26 MBytes  10.6 Mbits/sec                  
[  5]  89.00-90.00  sec  1.31 MBytes  11.0 Mbits/sec                  
[  5]  90.00-91.19  sec  283 KBytes  1.95 Mbits/sec                  
[  5]  91.19-92.54  sec  525 KBytes  3.18 Mbits/sec                  
[  5]  92.54-93.00  sec  785 KBytes  14.0 Mbits/sec                  
[  5]  93.00-94.69  sec  988 KBytes  4.79 Mbits/sec                  
[  5]  94.69-95.00  sec  402 KBytes  10.6 Mbits/sec                  
[  5]  95.00-96.00  sec  81.0 KBytes  664 Kbits/sec                  
[  5]  96.00-97.56  sec  948 KBytes  4.98 Mbits/sec                  
[  5]  97.56-98.57  sec  24.2 KBytes  196 Kbits/sec                  
[  5]  98.57-99.00  sec  600 KBytes  11.4 Mbits/sec                  
[  5]  99.00-100.20 sec  380 KBytes  2.59 Mbits/sec                  
[  5] 100.20-101.00 sec  1.52 MBytes  15.9 Mbits/sec                  
[  5] 101.00-102.62 sec  1.05 MBytes  5.45 Mbits/sec                  
[  5] 102.62-103.00 sec  213 KBytes  4.60 Mbits/sec                  
[  5] 103.00-104.00 sec  431 KBytes  3.53 Mbits/sec                  
[  5] 104.00-105.71 sec  1.25 MBytes  6.15 Mbits/sec                  
[  5] 105.71-106.00 sec  435 KBytes  12.3 Mbits/sec                  
[  5] 106.00-107.00 sec  1.67 MBytes  14.0 Mbits/sec                  
[  5] 107.00-108.00 sec  1.76 MBytes  14.8 Mbits/sec                  
[  5] 108.00-109.54 sec  633 KBytes  3.37 Mbits/sec                  
[  5] 109.54-110.00 sec  310 KBytes  5.52 Mbits/sec                  
[  5] 110.00-111.00 sec  89.6 KBytes  734 Kbits/sec                  
[  5] 111.00-112.66 sec  641 KBytes  3.16 Mbits/sec                  
[  5] 112.66-113.00 sec  208 KBytes  5.00 Mbits/sec                  
[  5] 113.00-114.00 sec  562 KBytes  4.60 Mbits/sec                  
[  5] 114.00-115.00 sec  765 KBytes  6.27 Mbits/sec                  
[  5] 115.00-116.00 sec  892 KBytes  7.30 Mbits/sec                  
[  5] 116.00-117.14 sec  145 KBytes  1.04 Mbits/sec                  
[  5] 117.14-118.42 sec  297 KBytes  1.90 Mbits/sec                  
[  5] 118.42-119.00 sec  502 KBytes  7.08 Mbits/sec                  
[  5] 119.00-120.19 sec  198 KBytes  1.36 Mbits/sec                  
[  5] 120.19-121.56 sec  641 KBytes  3.83 Mbits/sec                  
[  5] 121.56-122.68 sec  218 KBytes  1.59 Mbits/sec                  
[  5] 122.68-123.00 sec  65.4 KBytes  1.67 Mbits/sec                  
[  5] 123.00-124.00 sec  240 KBytes  1.97 Mbits/sec                  
[  5] 124.00-125.35 sec  434 KBytes  2.63 Mbits/sec                  
[  5] 125.35-126.00 sec  481 KBytes  6.06 Mbits/sec                  
[  5] 126.00-127.00 sec  99.5 KBytes  815 Kbits/sec                  
[  5] 127.00-128.00 sec  1.59 MBytes  13.4 Mbits/sec                  
[  5] 128.00-129.00 sec  1.65 MBytes  13.9 Mbits/sec                  
[  5] 129.00-130.00 sec  1.52 MBytes  12.7 Mbits/sec                  
[  5] 130.00-131.01 sec  27.0 KBytes  219 Kbits/sec                  
[  5] 131.01-132.08 sec  107 KBytes  816 Kbits/sec                  
[  5] 132.08-133.00 sec  1.31 MBytes  11.9 Mbits/sec                  
[  5] 133.00-134.32 sec  617 KBytes  3.83 Mbits/sec                  
[  5] 133.00-134.32 sec  617 KBytes  3.83 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-134.32 sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-134.32 sec  90.1 MBytes  5.62 Mbits/sec                  receiver
the client has terminatedprt = 4003cccc, reason = 1
-----------------------------------------------------------
Server [192.168.31.154] listening on [5201]
-----------------------------------------------------------

Hi Yuan,

It looks like this iperf3 log is different from the original issue, where originally the throughput went to 0Mbps. However, in this log, there is always some throughput being reported. Can you please clarify? Is this the original firmware from the R6 release, or the one Andres shared with you?

Also, it seems there is an issue with the firmware log. Can you please only share the pcap file that is outputted from Wireshark? I also see there are many times that 'dropped bytes' are reported. Can you verify that the correct logger.bin is being used to parse the LOGGER output?

Hi Sabeeh

I uploaded 3 log files, this time we used the FW Andres shared, and the logger.bin also is Andres shared.  I can't reproduce the throughput 0Mbps issue,  however, others can still reproduce this issue when using the auto power save mode. The logs I have indicate that the problem is on the PC side, where it stops sending data for 1 second. The root cause is that the firmware side fails to send an ACK packet in time for 1 second. This situation occurs very frequently, so I hope you can investigate this issue.

Hi Sabeeh,

Here is the log file which include wifi sniffer file. The log shows numerous instances of a 1-second data transmission gap.

Hi Sabeeh,

In `test3.7z`, there is a case which the throughput is entirely zero, and the port numbers for `iperf3` are `57755` and `57756`. You can search for `57756` in the log to see the relevant details.

-----------------------------------------------------------
Server [192.168.1.104] listening on [5201]
-----------------------------------------------------------
Accepted connection from 192.168.1.101, port 57755
[ 5] local 192.168.1.104 port 5201 connected to 192.168.1.101 port 57756
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 10.00-10.67 sec 81.3 KBytes 1.00 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-10.67 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-10.67 sec 81.3 KBytes 62.4 Kbits/sec receiver
prt = 4003cccc, reason = 1

Hi Yuan,

In this case, was power save set to ACTIVE?

Could you also specify the following information that is used on your system?

1. RTOS name or type? 

2. Networking stack? 

3. MCU host device?

4. mbedTLS version?

power save mode is auto.

rtos: ertos

network stack: lwip

mcu: oa8100

mbedTlS: 3.6.0

Hi Yuan,

Understood. Let me try to reproduce the scenario by dumping TCP packets from the CC33xx to another machine, so that the CC33xx is transmitting packets. Does this match your case as well?

Hi Yuan,

In addition, can you explain the iperf3 setup? Is the cc33xx running the iperf3 server, and then some other device is connecting to it? What device is IP address of 192.168.1.104 and what is IP address of 192.168.1.101? At what points were the TCP logs taken?

Hi Sabeeh

The CC33XX device is running an iperf3 server with the IP address 192.168.1.104. A PC, connected to the same AP via Ethernet (IP: 192.168.1.101), runs the iperf3 client. The log file named "pc_tcp_..." was captured on the PC side, while the other log comes from the CC33XX side.

Hi Yuan,

You previously mentioned that the TCP stack misses an ACK, but I don't see it in these logs. Can you share a screenshot or snippet of where you are seeing the ACK being missed?

Hi Sabeeh

I believe packets 17, 19 ... 29 were lost or blocked, which prevented the subsequent packet containing digit '2' from being transmitted, consequently resulting in the failure to initiate traffic flow.

Hi Yuan,

Just providing an update on this issue. We believe we have made some progress on this issue. I am attempting to get a build that should address it, and I will provide it to you as soon as possible. 

Hi Sabeeh

That's good news. A detailed schedule would be great!

Looking forward to your updates.

Hi Yuan,

While we believe we see the issue on our side, we want to be absolutely certain that it is the same issue on your end. This can only be confirmed with a wireless sniffer capture of the WiFi traffic between the Access Point and the CC33xx device. Would you be able to collect such wifi sniffer capture?

Could you also provide the make and model of the AP that you are using?

Hi Sabeeh

You can download wireless sniffer file from here:

The model of the AP is Redmi AX5 router

Hi Yuan,

I'm seeing some strnage things in the sniffer capture. Can you please suggest which is the MAC Address for the TI WiFi device you are using? Also, can you describe how these logs were taken? Are you running the full iperf application?

Hello Yuan,

Can we please get the additional information requested by Sabeeh?

These logs seem to have incomplete data and we cannot work with them, we really need to understand the issue on your end and make sure it is the same we have seen on our end.

Regards,
AB

Hi Sabeeh

Here is the relevant information about the test.

TI wifi device: 192.168.31.130, mac 54:42:67:46:df:c9

test pc: 192.168.31.93, mac 00:1c:23:03:8e:2f

After starting the iperf test, begin packet capture using OmniPeek. The iperf version being used is the full application.

Hi Sabeeh

Here is the new sniffer file which include the authentication/commisioing process, more information you can read readme.txt.

Thanks.

Hi Yuan,

I saw one frame in the sniffer capture here where the CC33xx says it's going to sleep. Can you please confirm if this test was conducted with WLAN_STATION_ACTIVE_MODE or AUTO?

Hi Yuan,

This sniffer is much more readable, so thank you for that. However, we are trying to chase the issue where the throughput drops to 0 for multiple seconds. In the iperf log, I see that the throughput momentarily drops to 0. Are you able to collect a sniffer capture where the throughput drops for a long time as reported before?

One additional question, it seems that both sniffer captures (wifi_sniffer_test5.pkt and pc_tcp_iperf3_test5.pcapng) dont line up. Meaning, we don't see the same TCP packets that are in both logs because the TCP sequence numbers do not contain the same values. Were these two captures taken at the same time?

Hi Sabeeh

the cmd "get_ps" shows it is active mode.

The packet captures were indeed taken simultaneously, and the port numbers match. The sequence numbers from the device side can be correlated.

The issue of the throughput drops to 0 for multiple seconds is hard to reproduce, anywhere I will try to reproduce it.

Hi Yuan,

Could you please suggest how to correlate the logs? Because we see from the TCP sequence numbers that they do not match.

For example, see the following two images from both captures. The Sequence value from within each TCP packet do not align to each other.

Indeed, the sequence numbers of the TCP packets sent by the PC in the two files do not match—possibly due to router tampering. However, to identify the same TCP packets across both files, we can still match them based on the TCP payload.

Now, we’ve found that the 244th packet in the **pc_tcp_payload_test5** file corresponds to the 1st packet in the **wifi_sniffer_test5** file. With this alignment, we can use these two packets as references to correlate all subsequent TCP packets.

I'm not sure what you mean, could you please provide a screenshot? Here is what I see and they don't match up. The TCP packets don't align either.

Anyhow, it would be best to provide capture of when the throughput drops completely. That will help us understand if there is a driver or underlying WiFi FW issue.

Hi Sabeeh

I made some modifications to pc_tcp_iperf3_test5 file by deleting the first 243 packets, so that the tcp sequence numbers can align with wifi_sniffer_test5 file.

Hi Yuan,

Thanks for this. I do see now that the packets initially do line up. They become out of sync due to the TCP [PSH,ACK] packets which seems like the AP is sending a smaller packet size which probably causes wireshark interpretation to be off as well.

Regardless, what we see in the sniffer log is that the communication is always active. TCP packets in wifi sniffer doesn't really slow down to match the throughput values that are seen in the serial console logs.

It is also interesting that this sniffer capture has different IP addresses from the images you sent about a month ago where the sniffer sees TCP Keep-Alive packets. Are you testing on a different AP? Can you retest and collect sniffer data on the scenario where we see the TCP Keep-alive packets?

Hi Sabeeh

The issue you mentioned is difficult to reproduce and may just be an isolated case. Previously, you mentioned that the issue could be reproduced on your end. Could you describe what the reproducible issue was? Has this issue been resolved? Also, is it possible to provide a new firmware for us to test?

Hi Yuan,

We believe the issue I was experiencing was with a misbehaving AP. The AP would send CC33xx data rates of MCS 8 on 2.4GHz, which is not supported by the ieee spec. The AP would then not retry the same packets at a lower rate causing the TCP session to be stuck. If I forced the same AP to use 11b or 11g rates, then I did not experience the same issue. 

We will be in touch with you regarding the new FW. 

Hi Yuan,

Could you also confirm if you are using CC3301 or CC3351 for your product?

We are using CC3301.