Is there a way to run this test normally? I tried to run it on x86_64
* make sandbox64_defconfig * enable CMD_BOOTEFI_SELFTEST configuration * run u-boot with "sudo ./u-boot -D"
type the following commands: => setenv autoload no; => setenv ethrotate no; => setenv ethact host_enp1s0; => dhcp; => setenv efi_selftest "http protocol" => bootefi selftest;
but DNS functionality does not work. I tried direct DNS querying with the same result
=> dns example.com UDP wrong checksum 00000001 0000e946 Timeout dns lookup of example.com failed, check setup
But wget, ping and some other commands works normally
=> ping 142.250.74.14 Using host_enp1s0 device host 142.250.74.14 is alive
Lets go back to a test. As I can see this test should not work et all. Current wget implementation requires "default server configuration" being set on target server. Unfortunately "http://example.com/" does NOT set default server configuration.
Thus wget open 93.184.215.14 server, then send the following request GET / HTTP/1.0\r\n \r\n Please note linux wget utility will send the following request GET / HTTP/1.0\r\n HOST: example.com\r\n \r\n (some meaningless headers were omitted).
As result in first case we tried to open default server. It's not configured, so we will get 404 error (Not Found). In the second case "example.com" server will be queried, so we get normal HTTP response.
I can patch wget, so it will send HOST header. Unfortunately it will require configured DNS. What do you think about it?
PS: Anyway, I found a bug (incorrect error handling) in my wget code, so I will send v16 anyway.
Mikhail Kshevetskiy
On 28.12.2024 00:00, Tom Rini wrote:
On Mon, Dec 23, 2024 at 01:58:41PM +0300, Mikhail Kshevetskiy wrote:
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:
so it's not possible to upload large amount of data from the board to remote host.
- data downloading from remote host to a board
- request-response exchange with a small packets
- 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)
This fails on the EFI self test on qemu-arm64. You can see this with "bootefi selftest" on the platform, and the excerpt from the full failure log at: https://source.denx.de/u-boot/u-boot/-/jobs/984858 https://dev.azure.com/u-boot/u-boot/_build/results?buildId=10224&view=lo... is: Setting up 'http protocol' succeeded Executing 'http protocol' 93.184.215.14 Packets received 5, Transfer Successful lib/efi_selftest/efi_selftest_http.c(216): ERROR: File not found lib/efi_selftest/efi_selftest.c(114): ERROR: Executing 'http protocol' failed Tearing down 'http protocol'