On Sat, Dec 20, 2003 at 12:12:41PM +1300, Dave wrote: > It looks to me that the TFTP server is being blocked. The pc makes the > request OK; the tftp server replies use this UDP port 516.
No. 516 is the size of the data contained by the UDP datagram. > Remember TFTP uses TCP to establish a connection, but UDP to send the > file. I think you'd better read RFC 1350. TFTP does not use TCP at all. > -----Original Message----- > From: chris bayley [mailto:[EMAIL PROTECTED] > Sent: Saturday, 20 December 2003 10:50 a.m. > To: [EMAIL PROTECTED] > Subject: PXE boot / tftp woes > tcpdump shows: > 10:41:25.114708 192.168.0.101.2070 > ruby.tftp: 49 RRQ > "pxe/eb-5.0.9-eepro100.lzpxe" > 10:41:25.117879 ruby.33589 > 192.168.0.101.2070: udp 516 (DF) > 10:41:26.111075 ruby.33589 > 192.168.0.101.2070: udp 516 (DF) > 10:41:28.111066 ruby.33589 > 192.168.0.101.2070: udp 516 (DF) You should be seeing TFTP ACKs from 192.168.0.101 to ruby. I suspect these are being dropped somewhere along the line. You didn't explicitly say where you're running tcpdump, but I assume you're running it on ruby. Check ruby's packet filter rules (if any are in place). Try and run tcpdump on another machine in the same Ethernet broadcast domain and compare that to the dump from ruby. You need to verify that the data packets from ruby to 192.168.0.101 that begin after the RRQ are being received by 192.168.0.101. Then you need to verify that 192.168.0.101 is sending TFTP ACKs back to ruby for each of those data packets. Obviously, part of this isn't happening--you need to find out whether the data packets or the ACKs are being dropped, and why. > I know RRQ is a read request, what is DF ? DF is an indication that the don't fragment bit has been set on the IP datagram. Mostly likely, this is because the machine "ruby" has an IP stack that supports path MTU discovery. Cheers, -mjg -- Matthew Gregan |/ /| [EMAIL PROTECTED]
