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 > [email protected] > http://etherboot.org/mailman/listinfo/gpxe-devel Guo-Fu Tseng _______________________________________________ gPXE-devel mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe-devel
