I get some very irritation Problems while booting an indy from network. BootP and TFTP are setup (on a debian x86 box) and appear to work. (tftp to the local machine does work)
booting the indy via tftp fails after the transmission of the first Block of the Kernel. --- i'm running 2.4.5 on my server box, and i did do "echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc" (otherwise i'd get an error even earlier) when i tell the indy to # boot -f bootp()vmlinux init=/bin/sh nfsroot=10.0.0.1:/home/indy/indy it does a successful bootp request > Setting $netaddr to 10.0.0.6 and starts downloading the kernel > Obtaining vmlinux from server > 1503232 But it then times out and fails > Error loading text section: cnt=0x130, expected 0x16f000. > Unable to load [...]: no such device In ethereal, i see the following: > BOOTP Request from the Indy (correct contents) > BOOTP Reply (correct contents) > TFTP Read Request from the Indy to the correct file > TFTP Data Packet to the Indy (512 Bytes, Block 1) > TFTP Ack by the Indy (Block 1) > TFTP Data Packet to the Indy (512 bytes, Block 2) Now it get's wired: after a 5 second delay i get > ARP request by the Debian Server > ARP reply by the Indy > TFTP Data Packet to the Indy (512 bytes, Block 2) another 5 sec delay > TFTP Data Packet to the Indy (512 bytes, Block 2) another 2 retransmissions so now about 30 seconds after the last Ack by the Indy, i get > TFTP Ack by the Indy (Block 1) another Block 1 ack??? > ICMP Destination unreachable by the Debian Server apparently the tftpd has given up by now. I tried tftp as well as tftpd-hpa; atftpd does work even less, but is reporting timeouts to the log file. So i'm not sure what's actually happening here. I'v read a bit into rfc 1350, but it looks to me like a error on the Indy side :-( The tftpd is waiting for an ACK of the second packet and times out; whereas the Indy, after some longer Timout of 30 Seconds does retransmit it's ACK and finally timed out as well after 120 seconds. So what's happening here? :-( i've checked the MACs of the packets, they are correct. ethereal runs on the tftpd server, i have a switch and cannot listen into the actual communication on the cable :-( but i don't think there's some filter blocking the second DATA packet, which somewhat isn't recieved by the indy. :-( Greetings, Erich
