Re: Re: [lwip-users] PCB states stay in FIN_WAIT_1

[jbtheou]

Thanks you for your answer. 

In fact, with Wireshink, i can see that nothing was send by PC (the other end). 
With LINK_STATUS, i can see that no packet was receive (until the first tcp state ESTABLISHED on log), but some packet was send. 
Memory used looks like OK (TCP_PCB memory is close of max some time, but no always, and other MEMP info is ok) and low_level_input (in ethernetif.c) aren't locked. 

Do you have another type of test ?

Thanks

Le 9 juil. 2010 17:05, Kieran Mansley <address@hidden> a écrit :
> On Fri, 2010-07-09 at 11:21 +0200, Theou Jean-Baptiste wrote:
> 
> > Hello everyone,
> 
> >
> 
> > I've a problem with lwIP (1.3.2 on atmel) on TCP/IP transmission. I
> 
> > use lwIP in FreeRTOS.
> 
> > In my project, web interface make an request (every 2 sec approx. ) to
> 
> > http server (who is on my embedded system) via
> 
> > http://192.168.0.120/CONFIG?blabla.
> 
> > Everything thing ok but after a while (seems random), request doesn't
> 
> > have answer anymore.
> 
> 
> 
> If you're sure the connections are stuck in FIN_WAIT_1 then we need to
> 
> consider why.  TCP connections can move from there to FIN_WAIT_2 if we
> 
> receive the ACK of our FIN, or to CLOSING if we receive a FIN from the
> 
> other end.  It sounds like we're getting neither.  This suggests that
> 
> something else is preventing the reception or processing of TCP
> 
> segments.  Could there be a resource like packet buffers that has become
> 
> exhausted, or some threading issue that has resulted in deadlock?  I
> 
> would investigate this sort of thing, particularly if you can get a
> 
> packet capture showing the other end cooperating by ACKing the FIN or
> 
> sending its own FIN which should be allowing lwIP to move those
> 
> connections on to the next states.
> 
> 
> 
> Kieran
> 
> 
> 
> 
> 
> _______________________________________________
> 
> lwip-users mailing list
> 
> address@hidden
> 
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>