read result with "0" implies EOF or error. Errno is not set, so as from busybox wget POV that is where the file ends. The bug is therefor not in busybox (apart not from showing user that Content-Length field and actual download mismatched).
Using wireshark, we see the entire HTTP request. This leaves us with the following possible culprits:
- virtio networking bug in foundation model
- virtio network driver bug in kernel
- eglibc
the read value of 0 is coming from the kernel, so eglibc is probably not the source (assuming strace is not confused).
Looking at where the strace ends:
strace -o test.log wget http:// kos.to/ porting- list.txt hashable_ 1.1.2.3- 1."..., 4096) = 4096 hashable_ 1.1.2.3- 1."..., 4096) = 4096 happstack- ixset_6. 0.1-2." ..., 4096) = 4096 happstack- ixset_6. 0.1-2." ..., 4096) = 4096 h/haskell- mersenne- random" ..., 4096) = 1320 h/haskell- mersenne- random" ..., 1320) = 1320
...
read(3, "able/haskell-
write(4, "able/haskell-
read(3, "haskell-
write(4, "haskell-
read(3, "iverse/
read(3, "", 4096) = 0
write(4, "iverse/
read(3, "", 4096) = 0
read result with "0" implies EOF or error. Errno is not set, so as from busybox wget POV that is where the file ends. The bug is therefor not in busybox (apart not from showing user that Content-Length field and actual download mismatched).
Using wireshark, we see the entire HTTP request. This leaves us with the following possible culprits:
- virtio networking bug in foundation model
- virtio network driver bug in kernel
- eglibc
the read value of 0 is coming from the kernel, so eglibc is probably not the source (assuming strace is not confused).