[gPXE-devel] [tcp] Fix error ACK number in FIN packet.

Guo-Fu Tseng cooldavid at cooldavid.org
Wed May 19 08:22:31 EDT 2010


On Wed, 19 May 2010 19:48:37 +0800, Guo-Fu Tseng wrote
> On Wed, 19 May 2010 11:44:09 +0100, Michael Brown wrote
> > On Wednesday 19 May 2010 11:16:51 Guo-Fu Tseng wrote:
> > >     In recent TCP stack testing, I've found that the FIN packet is
> > >  in-correct while downloading with HTTP. The attach shows the data before
> > >  and after this is fixed.
> > 
> > Nice catch.  It's probably neater to move the call to tcp_rx_seq() 
> > above the call to xfer_deliver_iob(), rather than using a hack to work 
> > around the problem.
> > 
> > A consequence of making this change is that you would then have to 
> > treat xfer_deliver_iob() errors as fatal to the connection, but that's 
> > arguably a good idea anyway.
> > 
> > Michael
> Actually, I did consider to send a patch like exactly what you said. :)
> 
> The reason I choose to send this one is it seems to me that letting
> rx path complete it's job in normal flow would make it easier to
> understand.
Here is another reason which I forgot while typing last e-mail:
If the last data packet contains FIN flag, or the timestamp just
changed, re-ordering tcp_rx_seq will also lead to TCP behavior error.

> 
> And the condition in tcp_xfer_close() can be seen as called by upperlayer
> due to receive complete, or by the upplayer actively wants to turn down
> the connection.
> 
> However, I totally agree this is a workarround, and there should be
> a better way to fix it. I'll see if any good idea comes to my mind.
> 
> If someone have idea about how to fix it would help me a lot. :)
> 
> Guo-Fu Tseng
> _______________________________________________
> gPXE-devel mailing list
> gPXE-devel at etherboot.org
> http://etherboot.org/mailman/listinfo/gpxe-devel


Guo-Fu Tseng



More information about the gPXE-devel mailing list