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: >> - 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) > 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=logs&s=664d8594-b731-54d7-afc5-7167226e08f3&j=52970d71-9fb7-5005-2ae1-66817be903ba > 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' >
