CC3000 troubles with "large" file download

Hi Victor,

Would it be possible to get the dumps from the CC3000 host driver, so that we can know at what stage this is getting stuck?
With release 1.14, we have introduced new ARP unsolicited events, and it is suggested to handle these events. (processors.wiki.ti.com/.../CC3000_Host_Programming_Guide). Let me know if you are seeing any issues with this regard.

Can you please give me a basic idea of what you are doing in your test?

Regards,
Raghavendra

Raghavendra Shenoy thank you very much for the prompt response. I'm literally just trying to download this file into the host processor in my test update.wickeddevice.com/test.hex.

Your suggestion on handling ARP unsolicited events is a good one, though I'm not sure how to tell whether this is the root cause. The only example given there is using it as part of UDP client, can you give any guidance on how it might be used in TCP?

Code like this (in the UDP example):
while(ulArpStatus == ARP_INIT || ulArpStatus == ARP_IN_PROGRESS);

... seems kind of perilous, at least without understanding underlying behavior of the CC3000 that gets me out of the loop.

Ultimately all that's happening (after establishing the tcp connection) is calling "recv(_socket, buf, len, flags);" and "select(_socket+1, &fd_read, NULL, NULL, &timeout);" in a loop... The loop terminates if the HCI_EVNT_BSD_TCP_CLOSE_WAIT event is received by the CC3000_UsynchCallback handler.

I'm happy to try and help get this ARP handling implemented, but I really need guidance in how to do it (currently the reference to the host programming guide is inadequate for my level of understanding). What should the host processor do if ulArpStatus == ARP_INIT? What should the host processor do if ulArpStatus == ARP_IN_PROGRESS? When should the host processor set the ulArpStatus to ARP_INIT? Subsequent to doing that should it just halt network activity indefinitely until that's not the case anymore (i.e. ulArpStatus == ARP_DONE)? Under what circumstances should all this be done?

One thing I can probably do as a start would be to add the code the the CC3000_UsynchCallback and see what the value of ulArpStatus is if/when the loop terminates if I initialize it to ARP_INIT. Would that be useful?

Raghavendra Shenoy I have done a packet capture from the server to which the CC3000 is connecting using the following command: tshark -f"host 67.255.5.128 and port 80" -w capture.pcap. That packet capture is attached in hopes that perhaps it gives some insight into what's going wrong. Please can you take a look and see if it helps?

5758.capture.zip

Hi Victor,

Thanks for the capture. Your understanding about the ARP events are correct. As you are not seeing any ARP events, you can ignore handling these events.

I did take a look at the capture, but it looks like the remote device failed to respond to the FIN,ACK sent from CC3000. Is it the same case where CC3000 received 'HCI_EVNT_BSD_TCP_CLOSE_WAIT'? Because in this particular case the remote device is in CLOSE_WAIT state.

For the case where we receive HCI_EVNT_BSD_TCP_CLOSE_WAIT, can you please try to mask this event from the host application and share your observation?

Regards,
Raghavendra

Raghavendra Shenoy Sorry for the lag in reply on my end. I had a large tree fall at my home and take out power, so I've been without (and am still without) power since last Friday. So let me check, that I understand what you want me to do. You want me to instrument the software to print out which events are being indicated by the CC3000 via the CC3000_UsynchCallback interrupt handler? And then also, in a separate test, you'd like me to remove the handling of the HCI_EVNT_BSD_TCP_CLOSE_WAIT and see what ensues? Do I have that right?

Raghavendra Shenoy I have more/new information now. It's not the HCI_EVNT_BSD_TCP_CLOSE_WAIT that's responsible, that was just an artifact of application-level timeout. If I remove the application level timeout, I find that the call to:

select(_socket+1, &fd_read, NULL, NULL, &timeout);

... returns 0 for long periods of time in between brief bursts of activity.

For example:
timestamp (ms), burst_bytes_rx , total_bytes_rx
26090, 16790, 16790
26809, 730, 17520
26871, 730, 18250
27365, 730, 18980
27424, 730, 19710
28382, 730, 20440
28440, 730, 21170
30329, 730, 21900
30392, 730, 22630
34145, 730, 23360
34203, 730, 24090
41681, 730, 24820
41747, 730, 25550
56657, 730, 26280
56723, 730, 27010
86512, 730, 27740
86575, 730, 28470
146096, 730, 29200
146160, 730, 29930

What next steps would you like me to perform to help get to the bottom of this?

Raghavendra Shenoy could it have something to do with HTTP headers? Perhaps I need to specify "Connection: keep-alive"?

Hi Victor,

Apologies for the delay.

For the case where you are using select, is the wireshark showing different sequence from the ones that you shared earlier? The earlier logs showed symptoms of improper close sequence. Are they showing the same symptoms during close? Or are they getting stuck somewhere else?

Regards,
Raghavendra

Raghavendra Shenoy I can attempt to do a server-side packet capture from a working network, and a server-side packet capture from a non-working network. In the case where I disable timeouts at the application level (i.e. forced client-side socket close), on the non-working network I think the session doesn't close so I'll just terminate the capture after a period of time (e.g. 5 minutes). I'll also provide timing debug output from the CC3000 side as before (i.e. time stamp, transfer size, total size) for both cases. Please confirm if that is what you'd like me to do.

Do you have any confidence that me going through all this effort result in an actual solution, or do you think there will just be more questions?