LwIP echoclient RAW example comments

[JMarq.1]

I wish this thread could be a community documentaiton to analyze and understand LwIP RAW echoclient example provided in firmware packages. It would be nice to open new threads for each example.

First question regarding this example: in tcp_echoclient_recv why the code tries to send remaining data if remote socket was detected as closed? It makes no sense to me. Any clue?

 /* if we receive an empty tcp frame from server => close connection */

 if (p == NULL)

 {

  /* remote host closed connection */

  es->state = ES_CLOSING;

  if(es->p_tx == NULL)

  {

    /* we're done sending, close connection */

    tcp_echoclient_connection_close(tpcb, es);

  }

  else

  {

   /* send remaining data*/

   tcp_echoclient_send(tpcb, es);

  }

  ret_err = ERR_OK;

 }

Thanks

[Mike_ST]

Hello,

What STM32 you're using ? What board ? what file ? What firmware package version ?

So people can look into the right place.

It seems like the code is just setting the socket state into CLOSING state because remote asked for it, which is not CLOSED state yet, and you might still have data to send.

[JMarq.1]

Hello,

The example is the same in MCUs F2, F4, F7 i bet it also in H7. Anyway, I'm currently using NUCLEO-F207ZG, but any answer based on LwIP RAW API will be welcome (no RTOS).

I'm based on firmware package:

\STM32Cube\Repository\STM32Cube_FW_F2_V1.9.3\Projects\STM322xG_EVAL\Applications\LwIP

I guess this echoclient TCP example is the same since 2015 or some years ago.

I cannot imagine in which situation an empty packet might arrive, unless the remote software is explicitly programmed to send such paquet to mark a disconnection request. Might this be the case? Is this example prepared to be used only with the software echotool provided and not being used with Putty/Hercules/YAT or similar tools?

Thanks

[Bob S]

The "empty frame" means a TCP packet with not data. But the TCP HEADER in that "empty" packet has a flag that signals the close request (the "FIN" flag).

The TCP protocol attempts to provide "guaranteed delivery" of data. The code you mention shows that the remote end has requested to close the socket. Your (local) end still has data that it needs to send. So it tries to send that data before completing the close sequence.

[JMarq.1]

Hi @Bob S​ 

Thanks for your answer and clarification. I've never seen such situation on a Wireshark captures (to receive a "FIN" previous to send all expected data to the remote site) but it might be the case and the code tries to protect it. OK. Thank you.

[Bob S · Accepted solution]

It is more "receive a FIN from the other end while this end still has data to send".

The side that initiates the FIN must either have already sent all its data, or the packet that contains the FIN also contains the last of the data. Once you send a FIN, you can no longer send any "new" data.

Feel free to flag my answer as "best answer" :) and make this thread as solved

[JMarq.1]

Sorry, my mistake: i meant (to receive a "FIN" previous to send all expected data to the remote site) instead of (to receive a "FIN" previous to receive all expected data). I corrected right now my previous post.

Anyway, I do understand what you are exposing. Thanks for your clarifications. I'm marking your answer as best answer.