June 22nd
"My Problem has been confirmed."
I had a look on the TI Forums and it appears that some one else has encountered the same issue.
It's listed under "cc3000 socket API recv() does not return correct data".
The recv() and recvfrom() functions are identical apart from the fact that recv() is for TCP and recvfrom() is for UDP.
Attached is the response from the TI engineer who investigated the problem.
Please find below the analysis done so far.
Test setup: a laptop connected to an AP via Ethernet cable and CC3000 connects via WiFi. The laptop has a simple application to connects to the CC3000 over TCP and sends data in small chunks of 4 bytes.
Issue description: it is conclusive that CC3000 gets the first 4 bytes correctly but then the second chunk of 4 bytes is received with two zeros padding at the beginning. all the rest are thus shifted by two bytes.
Debugging: I opened a sniffer and I could see the extra two zeros transmitted by the AP although the length in the IP section is not counting for it. CC3000 should thus ignore this 2 zeros. Btw, when a Laptop replaced the CC3000, it is all OK.
So, I asked to change the size to 2 bytes, 5 bytes and 8 bytes. To my surprise, I found that when only 2 bytes are send/recieved, the padding on the first packet is 4 zeros. With 5 bytes, the padding is 1 zero. With 8 bytes there is no padding.
Another interesting observation: when the Laptop is connected with Ethernet, the problem is 100% reproduced and when it is connected with WiFi, it is not reproduced. Interesting right?
I guess you already see the common groung here. The minimum data length on the TCP layer is 6 bytes, hence the padding.
But why? this is just an educated guess but since the minimum IP packet is 64 bytes, and we have 18 bytes of Ethernet header (remember the Laptop is connected via Ethernet) + 20 bytes IP header + 20 bytes TCP header => 6 bytes are left for data. Thus, a padding is required.
If you follow the same logic, with UDP it is even worse since the UDP header is much smaller so the minimum UDP payload is larger.
Btw, it makes sense why it works with WiFi, since the WiFi header is 24 bytes and not 18 bytes (so there is no restriction on the minimum).
Implications: this issue is not blocking in any way.
The reason for it is that the tests you applied are artificial tests where only TCP level is transmitted and not higher level.
In practice, some kind of application would always be necessary so the minimum payload of 64 bytes should be achieved.
Solution: it should be fixed in next releases
This is quite interesting because I too have my test PC connected to the Access Point using wired ethernet.
I shall connect using WiFi to see what difference it makes.
