Re: [lwip-users] TCP fragmentation over PPP - fragments are lost in LwIP if data is queued for sending

[Neil Turner]

Ok I understand that, however in this case the stack should not send ANYTHING if it cannot send the whole message.

 

As far as I can tell the interface will not return ERR_WOULDBLOCK to the API in this case, it will return ERR_OK in which case the application believes the whole message has been sent when it hasn’t. As far as I can tell the application has no idea how much of the message has been sent so cannot know what it has to resend.

 

The code below from do_writemore() in api_msg.c shows it only returns ERR_WOULDBLOCK if there is no available space in TCP if the is some space it carries on and sends what it can. I think in the ‘dontblock’ case this test should be if (len > available) return ERR_WOULDBLOCK, this would solve the problem we are seeing as the application can resend the whole message.

 

    available = tcp_sndbuf(conn->pcb.tcp);

    if (available < len) {

      /* don't try to write more than sendbuf */

      len = available;

      if (dontblock){

        if (!len) {

          err = ERR_WOULDBLOCK;

          goto err_mem;

        }

      } else {

#if LWIP_TCPIP_CORE_LOCKING

        conn->flags |= NETCONN_FLAG_WRITE_DELAYED;

#endif

        apiflags |= TCP_WRITE_FLAG_MORE;

      }

    }

 

Comments?

mit freundlichen Grüßen / with best regards
Neil Turner
          
Funk-Electronic Piciorgros GmbH
Claudiastr. 5 * 51149 Köln-Porz
Tel.: +49 2203 911 77-0
Fax: +49 2203 913 006
http://www.piciorgros.com
Erfüllungsort: Köln · HRB: 30112 ·   USt-IdNr. DE 812 452 161 ·   Geschäftsführer: Dipl.Ing. Petra Piciorgros und Dipl.Ing. Michael D. Piciorgros

 

From: lwip-users [mailto:address@hidden On Behalf Of address@hidden
Sent: 25 November 2016 19:15
To: Mailing list for lwIP users <address@hidden>
Subject: Re: [lwip-users] TCP fragmentation over PPP - fragments are lost in LwIP if data is queued for sending

 

Neil Turner wrote:

Looking at api_msg.c line 1254 it check TCP and only sends as much data as will fit in TCP (648 bytes in the case above). However after this check at line 1291 it then does,

 

if ((conn->write_offset == conn->current_msg->msg.w.len) || dontblock)

{

        /* return sent length */

        conn->current_msg->msg.w.len = conn->write_offset;

        /* everything was written *

        write_finished = 1;

        conn->write_offset = 0;

}

Since “dontblock” is true in our case it sets write_finished = 1 which changes the connection state back to NETCONN_NONE so poll_tcp() will never send the remaining bytes into TCP……I think this is the problem, but I don’t understand quite enough to know the proper fix.

"dontblock" means you have a nonblocking socket (or netconn). Of course no more byte are written, as the thread would have to block and wait for an ACK to write more.

In the end, you said all day that you sent 2*1400 bytes but you didn't. You told the stack to write 2*1400 bytes if it can without blocking...

Simon