Re: Re: [lwip-users] PCB states stay in FIN_WAIT_1
From:
jbtheou
Subject:
Re: Re: [lwip-users] PCB states stay in FIN_WAIT_1
Date:
Fri, 09 Jul 2010 15:30:50 +0000
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 >