Re: [lwip-users] netconn/netbuf api with receiving timeout missing closed connection

[Dmitri Snejko]

Kieran Mansley wrote:
> On Tue, 2009-11-03 at 23:39 -0500, Dmitri Snejko wrote:
>
>   
> > >   
> > >       
> > Hello Kieran,
> >
> > I have found the reason why the closed connection was missed with 
> > receiving timeout set to 0. It was my application problem. The remote 
> > side application was closed and windows stack sent RST. Netconn_recv set 
> > err to  ERR_RST. My application tried to close the netconn calling 
> > netconn_close, netconn_delete. Netconn_close nether returned back 
> > frizzing the receiving task.
> >     
>
> That sounds like a bug.  Could you file a bug report on savannah?
>
>   
I traced it down. This lock  happens with  LWIP_TCPIP_CORE_LOCKING  
only.  When  netconn err  is ERR_RST  netconn->pcb.tcp is set to NULL .
Call back do_close:
void
do_close(struct api_msg_msg *msg)
{
#if LWIP_TCP
 if ((msg->conn->pcb.tcp != NULL) && (msg->conn->type == NETCONN_TCP)) {
     msg->conn->state = NETCONN_CLOSE;
     do_close_internal(msg->conn);
     /* for tcp netconns, do_close_internal ACKs the message */
 } else
#endif /* LWIP_TCP */
 {
   msg->conn->err = ERR_VAL;
   TCPIP_APIMSG_ACK(msg);
 }
}

in this case supposed to call macro TCPIP_APIMSG_ACK(msg) which is 
defined empty  for   LWIP_TCPIP_CORE_LOCKING. As result the application 
layer blocks on waiting  conn->op_completed semaphore.
Instead netconn_delete calls do_delconn which in the same situation does:

 if (msg->conn->op_completed != SYS_SEM_NULL) {
   sys_sem_signal(msg->conn->op_completed);

and survives. Should we call  it  a bug?    LWIP_TCPIP_CORE_LOCKING is 
experimental.

Regards,
Dmitri,