TCP deadly embrace after ARP request.

Note that this is a separate and distinct problem from the other thread.

It occurs much earlier in the life of the session.

Hi Andy,

Is your network congested? If yes, can you please try it at a place where there is little less traffic around and share your observation?

Thanks & Regards,

Raghavendra

Network traffic is normal.

The CC3000 needs to work on normal networks, I'm not following the logic of your request.

To me, it is enough that this occurs, proving it might not occur on some other arbitrarily quiet network seems tangental at best.

Do you need verification that on a quiet network, the ARP request is made (despite having aucARP == 0), but the deadly embrace does not occur ?

How large is the ARP cache within the CC3000 ?

I ask to establish whether other hosts on the network could be causing the arp cache to be thrashed, spilling the entry this TCP session is using, hence causing the ARP request (despite aucARP == 0)

None of which makes the deadly embrace acceptable.

Hi Andy,

I am trying to understand the response time of ARP requests here. Because in cases where ARP response is delayed there could be reordering or missing IP packets which was waiting to be resolved.

It for sure is not acceptable under normal circumstances. I am trying to understand the scenario where I can have this done at my end.

Thanks & Regards,

Raghavendra

The tcpdumps clearly show the ARP response time is sub-millisecond.

Hi Andy,

Yes, I did see that. I wanted to figure the optimum response time and also to understand if this indeed is a problem with response time-outs. Anyways, I will try this at my end and let you know.

Thanks & Regards,

Raghavendra 

To all intents and purposes, I think those responses are functionally instantaneous.

I believe the deadly embrace occurs due to a buffer management/exhaustion condition.

The traces show a situation where two packets have been received, and perhaps one has been transmitted, when an ARP request occurs (despite setting the arp timeout to zero.)

The cloud-based application these CC3000s are talking to was recently modified to send a single 34-byte packet instead of the 2 + 32 byte sequence shown in these tcpdumps. The result is that I no longer see the deadly embrace, leading me to believe that the reduced stress on the buffer pool is key to avoiding the problem.

Attached is a tcpdump and matching debug logs from pins 2 and 4.

The deadly embrace occurs for packets 6721 thru 6754.

Note also the arp activity at packets 6697 & 6717. This after setting the arp timeout parameter to zero, and is immediately followed by the deadly embrace.

8561.20140208-1.zip