# TCP + IP, Lost data **URL:** \ **Category:** Libraries\ **Created:** [April 19, 2021, 8:19am UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364 "2021-04-19T08:19:49Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![daerid](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@daerid](https://forums.freertos.org/u/daerid)\ **Post date:** [April 19, 2021, 8:19am UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/1 "2021-04-19T08:19:49Z")
Hi there, I am using TCP + IP interface in my multi thread application. It’s working well except one time, when I am waiting for an acknowledgement from the server. The message only contains 1 byte. I have timeout, so my network task is in blocked state and waiting for any message, but I don’t get any. I have some short atomic functions which is used by other threads. Is it possible, those atomic functions cause this issue? Looking forward for your reply, Kind regards, David ---
**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\ **Post date:** [April 19, 2021, 8:42am UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/2 "2021-04-19T08:42:14Z")
I don’t think that some other atomic functions (I guess some short pieces of code in critical sections) cause this. Are you sure (Wireshark ?) that the message was sent in time by the peer ? Did you set TCP\_NODELAY socket option on the peer to disable Nagle’s algorithm ? ---
**Author:** ![daerid](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@daerid](https://forums.freertos.org/u/daerid)\ **Post date:** [April 19, 2021, 9:03am UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/3 "2021-04-19T09:03:56Z")
Hi, I’ve not seen the message in wireshark, but I do not see any of them after get connected. I’m connected to the same hub, but I only see the ARP messages. Actually, I’ve tried to configure the socket to this communication, so to avoid message losing, I’m using a much higher value to get timeout, than the interval of acknowledge. The server part wasnot written by me, but we have different devices, which communicate with server correctly. Regards, ---
**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\ **Post date:** [April 19, 2021, 9:10am UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/4 "2021-04-19T09:10:05Z")
> [@daerid](#): > > I’m connected to the same hub, but I only see the ARP messages. That means it is not a hub but a switch. You need to get a very dumb hub such as an old blue netgear box to plug in between your target and the machine running wireshark. Don’t throw the old stuff away! 🙄 ---
**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\ **Post date:** [April 19, 2021, 9:33am UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/5 "2021-04-19T09:33:38Z")
Ok - if other devices using the same protocol (with 1 byte ACK message) are fine, it could be an issue with your application and/or the FreeRTOS TCP stack configuration. You’re using FreeRTOS+TCP stack ? What’s your MCU ? Is the TCP connection still there after sending the ACK msg ? If not which peer closes the connection ? ---
**Author:** ![daerid](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@daerid](https://forums.freertos.org/u/daerid)\ **Post date:** [April 19, 2021, 10:55am UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/6 "2021-04-19T10:55:14Z")
Unfortunately, I do not have hub, It’s true it is switch my baad, thanks your response. I’ve learned new today! ---
**Author:** ![daerid](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@daerid](https://forums.freertos.org/u/daerid)\ **Post date:** [April 19, 2021, 11:01am UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/7 "2021-04-19T11:01:57Z")
Yes, I’m using FreeRTOS+TCP stack. My MCU is EK-RA6M3 MCU from renesas, it has Arm Cortex M4 cpu. I can see the message was sent from the server, and the connection is still alive after the ACK msg. The connection will be closed by server, after I couldn’t recognise 3 of ACK msg. (It’s around 3 mins.) ---
**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\ **Post date:** [April 19, 2021, 11:06am UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/8 "2021-04-19T11:06:29Z")
ok, what you can try to do then IF you happen to have a 2nd network card on your PC is let that network card act as a switch on which only your target is plugged in (P2P) and add the necessary routing info on your machine. That way you can wireshark that interface. Some switches also keep different logical segments for different negotiated speeds, so something that might help in seeing all traffic is nailing the ethernet interface’s speed to the one that matches your logging PC instead of allowing auto negotation (or vice versa nail the PCs speed to match your target’s). Being able to analyze network traffic is absolutely crucial to network debugging, so I’d rather go through some trouble setting up a reliable way to sniff the traffic than guessing… ---
**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\ **Post date:** [April 19, 2021, 12:00pm UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/9 "2021-04-19T12:00:29Z")
That’s strange … is `FreeRTOS_recv` waiting forever for the 1 byte ACK packet or do you encounter a socket error ? Are you able to recv other/larger data packets ? Do you’ve access to the server log ? Is there a socket error on the server after sending the ACK packet (like ECONNABORTED) ? If not, the packet was sent and TCP-acknowledged by the board successfully. ---
**Author:** ![daerid](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@daerid](https://forums.freertos.org/u/daerid)\ **Post date:** [April 19, 2021, 12:12pm UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/10 "2021-04-19T12:12:22Z")
The ACK msg should be received in every minutes, if you don’t get any of other requests from the server. I’ve no lost any of longer messages, and sometimes a can catch the ACK msg too. I though that, if my socket has 70 seconds of timeout counter, it would be fit well, but it’s not. I’ve got 2 times 0 length message, and after that I got an error -128 which means, The server get disconnected. ---
**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\ **Post date:** [April 19, 2021, 12:14pm UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/11 "2021-04-19T12:14:33Z")
What you should do is run ICMP requests forever in parallel, ie ping -t [your device]. It’s a good diagnostic, because when you lose your ICMP responses when the ACKs are dropped, you know it’s rather a general problem with the stack than with the particular connection. ---
**Author:** ![daerid](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@daerid](https://forums.freertos.org/u/daerid)\ **Post date:** [April 19, 2021, 12:47pm UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/12 "2021-04-19T12:47:07Z")
I’ve started to ping the device. It should be error of stack, because I don’t even get any of ICMP responses neither after some mins. ---
**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\ **Post date:** [April 19, 2021, 12:52pm UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/13 "2021-04-19T12:52:28Z")
Could also be a config error. Did you enable `ipconfigREPLY_TO_INCOMING_PINGS` ? **Edit:** Do you get PING REPLYs at the beginning but not later on ? ---
**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\ **Post date:** [April 19, 2021, 12:56pm UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/14 "2021-04-19T12:56:41Z")
ok, then it may be the case that the TCP/IP task is hung or deadlocked. I’m not familiar with FreeRTOS’s TCP stack, but the basic strategy is the same for how I go about this with other stacks like lwip: Add counters to all functions that process incoming data. For example, every time an ethernet Rx frame is processed, increment a counter. Every time a packet is processed by the IP layer, increment another counter. Same for TCP etc. Same the other way arounf (that is, transmit). If your IDE allows you to watch the values of those counters in real time, you can visually follow where packets cease to be forwarded to the next layers. ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [April 19, 2021, 2:51pm UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/15 "2021-04-19T14:51:54Z")
> [@daerid](#): > > I have timeout, so my network task is in blocked state and waiting for any message, but I don’t get any. I have some short atomic functions which is used by other threads. Is it possible, those atomic functions cause this issue? This thread is becoming quite long and is mainly folks replying by asking questions. That is because your original post does not contain enough information for people to start to know what the issue might be. Grateful if in future you could start by providing more details (for example, in the above, what is the relevance of the atomic functions? What do they look like (code)? Also, what does “working well” mean - it could mean you are able to get a DHCP address or it could mean it runs for hours without any problem). Also it is best to start this kind of thread with a wireshark trace. If you do this the replies will be a lot more targeted and your issue will get solved faster with less effort. ---
**Author:** ![daerid](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@daerid](https://forums.freertos.org/u/daerid)\ **Post date:** [April 19, 2021, 2:53pm UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/16 "2021-04-19T14:53:02Z")
Yes, It is really strange. There is no fix command, which cause this stop. In this case, the task is stay in FreeRTOS\_recv function, but I don’t get any of message from the server. I’m sure it’s something like timing or stack issue. After I’ve shutted down the previous socket and create new one it’s working again for a short time. I’m trying to catch stack overflow, but I’ve not seen something like that however the configCHECK\_FOR\_STACK\_OVERFLOW is defined to 1. ---
**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\ **Post date:** [April 19, 2021, 3:19pm UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/17 "2021-04-19T15:19:08Z")
> [@daerid](#): > > I’m sure it’s something like timing or stack issue Hmm … I’m not so sure b/c the stack works very well in many, many applications (if configured right). The ethernet driver might also have issues, which is the custom/user provided part of the stack. Did you verify that you do not run out of memory / network buffers and which buffer allocation scheme do you use for TCP stack ? I guess you did define [configASSERT](https://www.freertos.org/a00110.html?_ga=2.213540052.1971135108.1609110559-800452554.1575115350#configASSERT). When in doubt I’d propose to set `configCHECK_FOR_STACK_OVERFLOW` to 2. And … which FreeRTOS and TCP stack versions do you use ? ---
**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\ **Post date:** [April 19, 2021, 3:25pm UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/18 "2021-04-19T15:25:32Z")
If it’s a recv with timeout, as you wrote earlier, then if the code never returns from your receive, either the freertos timer task or the tcp task is deadlocked. Do other software timers still run in the error case? ---
**Author:** ![kanherea](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/kanherea/32/4106_2.png) [@kanherea](https://forums.freertos.org/u/kanherea)\ **Post date:** [April 20, 2021, 1:53am UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/19 "2021-04-20T01:53:23Z")
> [@daerid](#): > > It should be error of stack, because I don’t even get any of ICMP responses neither after some mins. Does your board happen to have debugging capabilities? If so, and if you can control the server, you can actually track the packet through the TCP stack. And route cause why and when the packet was discarded. Since you are not doing something very out of the ordinary with packets (such as modifying flags etc), the +TCP stack should be able to handle this quite easily and gracefully if configured correctly. ---
**Author:** ![daerid](https://avatars.discourse-cdn.com/v4/letter/d/e9c0ed/32.png) [@daerid](https://forums.freertos.org/u/daerid)\ **Post date:** [April 20, 2021, 7:47am UTC](https://forums.freertos.org/t/tcp-ip-lost-data/12364/20 "2021-04-20T07:47:49Z")
Thank you so much for your replies, I’ve learn a lot of new things, what I could check, and what’s the image of these all. It’s working as it’s expected. The Critical section caused my problem. I have a big data structure which is stored, and to write and read I’ve used Critical\_section, which was disabled my interrupts. I guess the interrupts caused deadlock of my stack. I’m appreciate your kindness and help. Regards, David