[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