[bug #26672] close connection when receive window = 0

[Mario Castelán Castro]

URL:
  <http://savannah.nongnu.org/bugs/?26672>

                 Summary: close connection when receive window = 0
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: olegreen
            Submitted on: Mon 25 May 2009 02:25:46 PM GMT
                Category: TCP
                Severity: 3 - Normal
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release:
            lwIP version: CVS Head

    _______________________________________________________

Details:

lwip_close should close both directions send and receive.

lwip_close deletes data in receive buffer, but receive window won't be
updated.

If it was situation with zero receive window,
other side can't send FIN, because receive window = 0.

In do_close_internal() will be only tcp_close() called.
It is necessary here set initial receive window.






    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26672>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Mario Castelán Castro]

Update of bug #26672 (project lwip):

         Planned Release:                         => 1.4.0                  


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26672>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Mario Castelán Castro]

Follow-up Comment #1, bug #26672 (project lwip):

This is a bit tricky: I'd suggest draining the recvmbox/acceptmbox from
netconn_delete before calling do_delconn. This would mean that after a call to
lwip_close/netconn_delete, no more data can be received, but that's what we
want.

I'd add a new function netconn_drain, that drains and frees conn->recvmbox
and conn->acceptmbox while calling tcp_recved() and tcp_accepted() so that the
counters are correct afterwards.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26672>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Mario Castelán Castro]

Follow-up Comment #2, bug #26672 (project lwip):

Since I tested it and it's mainly code moved to another location, I'd regard
this as low risk (meaning 1.3.2), any thoughts on that?

Currently, recvmbox/acceptmbox are drained in the application thread, in
netconn_delete->neconn_free (after do_delconn).

The attached patch moves the draining into an extra function (netconn_drain),
which is called from netconn_delete *before* calling do_delconn. The amount of
drained data is passed to do_delconn (tcpip_thread), which can call
tcp_recved/tcp_accepted accordingly.

The only downside of this approach is that, while draining, recvmbox &
acceptmbox are set to NULL from the application thread, meaning there is a
tiny gap where recv_tcp/accept_function may see them as NULL and must handle
that correctly (covered by the patch).

I have tested it and together with a bug-fix in the TCP_EVENT_RECV macro (has
to call tcp_recved if pcb->recv is NULL), it works decently (remote side can
transfer data until it closes the connection, but that's another bug).

(file #18940)
    _______________________________________________________

Additional Item Attachment:

File name: lwip_26672_1.patch             Size:7 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26672>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Mario Castelán Castro]

Update of bug #26672 (project lwip):

                  Status:                    None => In Progress            
             Assigned to:                    None => goldsimon              


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26672>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Mario Castelán Castro]

Follow-up Comment #3, bug #26672 (project lwip):

Let's hold this for 1.4.0

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26672>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Simon Goldschmidt]

Kieran Mansley wrote:
> Follow-up Comment #3, bug #26672 (project lwip):
>
> Let's hold this for 1.4.0
>  

What's the current timeplan on 1.3.2? As there are only few real bugs
open (that aren't feature requests), in my opinion we have two choices:
either
a) we get 1.3.2 out really fast now (bug #27445 is nearly solved, isn't
it?) or
b) we could decide to do a real bug-fix release in which we try to fix
all known bugs (which could take another month, of course).

Although I favoured a), I'm now tempted to vote for b), since it could
really be a while until 1.4.0 will be released, and it looks like that
one will have rather many new features, which makes it potentially
unstable again. Therefore, a "superstable" release before 1.4.0 (be it
1.3.2 or 1.3.3) would be a good idea.

Simon


_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Kieran Mansley]

On Mon, 2009-10-26 at 10:49 +0100, goldsimon@... wrote:
> in my opinion we have two choices:
> either
> a) we get 1.3.2 out really fast now (bug #27445 is nearly solved,
> isn't
> it?) or
> b) we could decide to do a real bug-fix release in which we try to
> fix
> all known bugs

I prefer (a).  We can always do another release in a few months if we
find we've fixed lots more bugs without any API changes.

I'll tag the tree for 1.3.2-rc1 later if I get the chance.

Kieran



_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[Simon Goldschmidt]

Kieran Mansley wrote:
> I'll tag the tree for 1.3.2-rc1 later if I get the chance.
>  
Great, Thanks! I hope that 1.3.2 final will follow soon.

Simon


_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel