search for: tftp_get_packet

...t; Implement a timeout, which is what all the other network stacks do. By > timing out we are now able to handle packet loss on the network, e.g. > we'll now re-send TFTP requests instead of waiting for ACK packets that > will never come. > Hmmm. We already have a timeout loop in tftp_get_packet() as well as in the legacy version of dns_resolv(). I would like to suggest we augment the generic UDP receive function call with a timeout, rather than implementing a timeout upon a timeout. What do you think? -hpa

Signed-off-by: Julien Viard de Galbert <jviarddegalbert at online.net> --- efi/udp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/efi/udp.c b/efi/udp.c index 1088f47..b0f13ad 100644 --- a/efi/udp.c +++ b/efi/udp.c @@ -163,7 +163,7 @@ void core_udp_connect(struct pxe_pvt_inode *socket, uint32_t ip, } else { udata.UseDefaultAddress = FALSE;

...the slave decides to crash before (or after?) the next file finnishes downloading. Even ldlinux can fail to load. On bigger files, there is an increasing chance that core_udp_recv in efi/udp.c hits the 15ms (or is it 15 undefined jiffies?) timeout and returns -1 to its caller in core/fs/pxe/tfpt.c:tftp_get_packet(). This function then goes to ack_again, causing atfptd to resend the packet that just timed out. Then on the next call the original(!) packet is received anyway and handled according to plan. But the next packet to be received will be the same packet again, causing tftp.c to hit this code:...

...sh before (or after?) the next > file finnishes downloading. Even ldlinux can fail to load. > > On bigger files, there is an increasing chance that core_udp_recv in > efi/udp.c hits the 15ms (or is it 15 undefined jiffies?) timeout and > returns -1 to its caller in core/fs/pxe/tfpt.c:tftp_get_packet(). > > This function then goes to ack_again, causing atfptd to resend the packet > that just timed out. Then on the next call the original(!) packet is > received anyway and handled according to plan. > > But the next packet to be received will be the same packet again, > causi...