Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Félix_T
Level 5
Level 5
10 sign-ins First comment on blog 50 replies posted

We have a socket defined as follows:

lwip_setsockopt(SSocket, SOL_SOCKET, SO_RCVTIMEO, &recv_timeout, sizeof(recv_timeout));

lwip_setsockopt(SSocket, IPPROTO_TCP, TCP_NODELAY, &recv_timeout, sizeof(recv_timeout));

It seems that sometimes, when we call

recvLen = lwip_recvfrom( SSocket, receive_buf, sizeof( receive_buf ), MSG_PEEK, NULL, NULL );

we do not always see data that should be on the socket.  We have wiresharked the connection to make sure that the data is present.  We see our request go out, and quickly see the response come back (100ms or so), but lwip_recvfrom can take up to three seconds before it reports that there is something on the socket.

Has anyone else experienced this?  Does the BCM43362 do internal packet stacking because our packets are fairly small (<60 bytes)?

0 Likes
1 Reply
Félix_T
Level 5
Level 5
10 sign-ins First comment on blog 50 replies posted

I figured it out.  The problem is actually the opposite.  lwIP does not stack packets when calling lwip_recvfrom.  We have a periodic packet, and a non periodic packet.  The receive expects a response from the periodic packet, but everytime we send the non period packet, the response caused by that packet adds one more packet to read onto the receive buffer.  Since lwip does not stack packets, we need to do extra reads to catch up, essentially always reading as many packets as available, otherwise we will be backing up by one packet everytime we send a non periodic packet, which pushes out our perceived received time by one more read window each time.