Merge patch series "net: tcp: improve tcp support in legacy stack"
Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> says:
Legacy TCP stack is bad. Here are some of the known issues:
* tcp packet from other connection can break a current one
* tcp send sequence always starts from zero
* bad tcp options processing
* strange assumptions on packet size for selective acknowledge
* tcp interface assumes one of the two scenarios:
- data downloading from remote host to a board
- request-response exchange with a small packets
so it's not possible to upload large amount of data from the
board to remote host.
* wget test generate bad tcp stream, test should fail but it passes instead
This series of patches fixes all of the above issues.
The benefits:
* A lot of bug was fixed
* Better and more reliable TCP state machine
* Tcp clients becomes smaller/simpler
* Data uploading was fixed (now it's possible to transmit a huge amount of
data from the board to remote host)
Modification was verified with
* firmware downloading via u-boot wget command
* fastboot over tcp
* netcat linux client using test netcat implementation (not included
to this patch series)
* Firefox/Chrome/Edge using test web-server implementation (not included
to this patch series)
[trini: snip]
WARNING: The v16 patch series does NOT fix lib/efi_selftest/efi_selftest_http.c
issue. It looks like the efi_selftest_http test is wrong by itself. The
following issues were detected during efi_selftest_http test study:
* The test should fail with HTTP status code 404 because:
* nowday most web-servers requires the presence of "HOST:" request header
* wget does not support sending "HOST:" request header
* web-server of "http://example.com/" site does NOT provide "default server"
configuration, so it answer 404 on any request without "HOST:" header.
* The test states that:
* test send HTTP HEAD request to a server,
* then test send HTTP GET request to a server,
* reads the actual bytes sent by the server and compare it with
the value from "Contents-Length:" responce header of the HEAD request
But actually it
* does not send HTTP HEAD request, only a single HTTP GET request
is performed
* the test reads the responce twice from the same request. It looks
very suspictiuos
Link: https://lore.kernel.org/r/20241228104637.4173913-1-mikhail.kshevetskiy@iopsys.eu