CC3220SF: TCP ACK Delay / 802.11 Frames are not received.

Hi Jaden,

We would need wireshark logs to understand why there is a TCP delay. Please provide this and explain why you think the stack is the problem.

Jesu

Hi Jesu.

I checked 802.11 frames and TCP packets using monitor mode.

192.168.10.1 : AP, TCP Server

192.168.10.2 : Station, TCP Client ( CC3220SF, AT Command Example )

Line 2265 & 2266 shows that 802.11 Acknowledgement frame were transmitted immediately after TCP PSH,ACK packet were sent.
But TCP ACK packet to the previous packet was sent after about 180ms.

and I checked that the same thing happened in the latest version. ( sdk v4.20.00.07 )

Can you tell me why it takes 180ms to send TCP ACK packet?

Best regards

Jaden

Hi Jaden,

Our TCP stack is built into the NWP so once you open a socket with our host driver the NWP will manage the rest of the socket and just notify the host whenever necessary. If the NWP is busy it may take some time to send ACK. 

I'm not sure what is going on - I need more information. If you are concerned about sharing sniffer capture publicly you can share it with me directly via private message. If you can share directly, please include packet numbers of when TCP packet is received and ACK is sent for said packet. 

Also, what HW are you using to capture wi-fi sniff logs? Some capture devices are not well suited for this and will not capture all packets.

Jesu

Hi Jesu.

Thanks for your reply.

My customer's application is monitoring message timeout (100ms) and it is not considering retransmissions.

So Wi-Fi module has to complete the transmission for less than 100ms.

Under normal conditions, ACK transmission takes less than 5ms.

But Occasionally it takes more than 180ms.

I don't think this is a problem. I just want to know what can cause NWP to be busy.

And I also want to know why the Wi-Fi module can't receive 802.11 frames intermittently.

I know that all packets can't be captured.

But I have confirmed several times that the Wi-Fi module is unable to transmit ACK on up to seven 802.11 retransmissions.

I also want to know if this can happen when NWP is busy.

If you can tell me how to send a private message, I can send you a wireshark log message.

Best regards

Jaden

Hi Jaden,

I sent you a friend request on E2E. Accept it and send me the sniffer log via private message. Please highlight where the long transmission occurs.

Also, what 802.11 frames is the CC32XX device expecting that you say it is not receiving? How are you measuring this?

Jesu

Hi Jesu,

I checked the sniffer log and found that STA did not receive the 802.11 frame until the 802.11 retransmission maximum count.

I sent you the sniffer log via private message. Please read README.txt.

Best regards

Jaden

Hi Jaden,

I received the logs. Thanks for providing. I see many occurrences throughout the capture where both the AP and the station are doing retransmissions. Is the customer using custom HW?

Also these are QoS data frame you are referring to. Are you sure the customer is using TCP? 

Jesu

Hi Jesu,

Both the customer and we use custom HW and TCP.

I captured 802.11 frames and decrypted using Wireshark decryption option.

Like you said, despite the good signal, a lot of 802.11 retransmissions occur.

But I don't know why a lot of 802.11 retransmissions occur.

Jaden

Could you run a test with a TI CC3220SF Launchpad? This would help us determine if there is HW or SW issue. Also, have you tried with different AP?

Jesu

Hi Jesu,

The same occurs in CC3220SF Launchpad.

I don't have tried with different AP.

However, my client said there was no problem when using another STA.

Jaden

Hi Jaden,

It's difficult to say without getting more detail. The logs you sent me are encrypted so I can't see TCP packets only QoS data. Is the CC3220 communicating with an external network? 

However, my client said there was no problem when using another STA.

When you say another station you mean another station doing the same thing as the CC3220? Is it another CC3220 operating as a station? 

Jesu

Hi Jesu,

The reason you can't see TCP packets is because the file I sent is not the entire file.

and another STA what I said is not CC3220SF. (Wi-Fi module made by another manufacturer)

If you need entire file, I will send you.

Jaden

Yes the entire file will be more helpful. I think you need to provide the key as well so I can decrypt the log but I'm not sure. 

Also, is the TCP socket communicating with an external server or device on the local network?

Jesu

Hi Jesu,

Sorry for the late reply.

SSID : JW1UD1GKG-0000

Password : WPT_GA_0000

TCP socket communicating use the local network.

Jaden.

TCP socket communicating use the local network.

To be clear, my question was if the TCP socket is communicating with an endpoint that is not on the same local network as the CC3220?

Also, I will check the logs now and get back to you. 

Jesu

Hi Jaden,

EDIT: Never mind. I did not see you sent me a private message. Let me check this one instead.

EDIT: These logs successfully decrypt the traffic. Thanks. I will review today and respond.

Jesu

Jaden,

Are you using HTTP and a separate TCP socket in your application? I notice the longer delays always occur when HTTP packets are being sent. Since HTTP works over TCP that would explain the delay.

Jesu