Re: [lwip-users] lwip 1.4 - no FIN sent!

[Stephane Lesage]

> > I suggest someone with TCP knowledge (simon, Kieran ?) takes a look
> at
> > this issue.
> 
> I'd be happy to, but I'll be away for a week or two on holiday.  If
you
> can get a simple test case that shows the problem, and a packet
capture
> to illustrate it, that would be extremely helpful.

False alert for the FIN !
The flag is set but it's not displayed in wireshark single line because
it's interpreted as an HTTP response.

m8847 you should check in the packet details.

I still have my last data packet not sent immediately after a close...

I may have the same problem as Richard Barry in "Delayed ACK causing
problems? Where to calltcp_nagle_disable()? "

As said by Felipe de Andrade:
"how came the Nagle's algorithm has caused the problem, as it is suppose
to group small data until receive the next ack, but the JPG has lots of
pending data to be sent and the algorithm shouldn't retain it."

When closing, tcp should also sent the pending data immediately, no ?
And I also noticed the window advertised by lwIP is weird.

In the attached capture we can see:
2. LwIP (192.168.10.151) accepts connection and advertise a 8192 bytes
window
4. browser (192.168.10.252) sends 338 bytes
5. LwIP acknowledges 338 bytes, sends 79 bytes, and advertises a 7854
bytes window
6. LwIP 338 bytes, sends 1460 bytes, and still advertises a 7854 bytes
window

At this moment, the browser request has already been read. So shouldn't
lwIP advertise 8192 again ?

10. last data sent by lwIP with FIN flag

Why wait the ACK in packet 9 to send the data ?

-- 
Stephane Lesage

close_delay_and_window.pcap
Description: close_delay_and_window.pcap