[En-Nut-Discussion] Suggested modification to nut\net\tcpsm.c again

ennut at thezachariasgroup.com ennut at thezachariasgroup.com
Thu Nov 12 13:39:58 CET 2009

   I have heartache casting the 32 bit result from NutGetMillis() to uint16_t.
   Doesn't it make more sense to define so_retran_time as u_long 
rather than u_short in sock_var.h ?

I didn't look at the code but I would check to see if the u_long 
result from NutGetMillis() is
stored in so_time_wait. If so I would change it to u_long.



At 04:54 AM 11/12/2009, you wrote:
>Some time ago Zack suggested a modification of the TCP state machine:
>I assume, that this one fixed the problem at that time. However, recent
>tests showed, that the problem is back again.
>I do not have a proof, just a strong feeling that somehow the way
>changed, the GNU compiler does calculations. Wasn't there similar fix
>required during the last months? I'm currently using GCC 4.4.2.
>Unfortunately the problem now appears more often after
>because so_retran_time may be 1 ms ahead.
>As a result, Ethernut sends duplicate segments quite often.
>Anyone else observed something similar with GCC calculation routines?
>The following change seems to fix it.
>  * Process retransmit timer.
>  */
>if (sock->so_tx_nbq && sock->so_retran_time) {
>   uint16_t millis = (uint16_t)NutGetMillis();
>   uint16_t diff = millis > sock->so_retran_time ? millis -
>sock->so_retran_time : sock->so_retran_time - millis;
>   if (diff >= sock->so_rtto) {
>     NutTcpStateRetranTimeout(sock);
>   }
>I'm afraid, that there are other parts of the OS/Net code failing with
>the latest GCC.

More information about the En-Nut-Discussion mailing list