Weird TFTP Problems while booting an SGI Indy
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
Reply to: