It kinda sounds like a general network problem to me...if you run: ifconfig -a

ifconfig -a shows errors: 0 dropped: 0 overruns: 0 for both RX & TX packets

Do you see many errors? If you do..run this: mii-tool

mii-tool shows "eth0: negotiated 100baseTx-FD flow-control, link ok

What is the duplex setting? Does it match what is on the other side (switch, or system if it is a cross-over cable) What is the link between the two systems? 100Mbit LAN, or are you going over a router or something?

I am not sure about the duplex setting ifconfig -a is not reporting it so I have assumed it to be auto. It is a straight LAN connection not going through any routers with only a switch between the boxes.

The mii-tool output will show you the duplex setting ("negotiated 100baseTx-FD" from above tells you that it is set to auto, and it has decided on 100Mbit-Full Duplex).

Are you seeing it timeout right away, or are there some bytes transferred, then times out?

I take it that you have checked for errors/duplex problems on both machines (as well as selinux/iptables)? What about tcpwrappers? /etc/hosts.allow and /etc/hosts.deny are blank?

Mike

...

Are you seeing it timeout right away, or are there some bytes transferred, then times out?

I am not seeing any bytes transferred. The time out is after the

default 25 sec.

...

I take it that you have checked for errors/duplex problems on both machines (as well as selinux/iptables)? What about tcpwrappers? /etc/hosts.allow and /etc/hosts.deny are blank?

Other than ifconfig how can I check for errors/duplex problems? I am

not seeing any errors

on other services running on either box but am willing to dig further.

These commands can show you more errors: netstat -su netstat -i

Neither box has selinux or iptables enabled. tcpwrappers is utilized

for tftp but both

hosts.allow & hosts.deny are empty. When I look a /var/log/secure it

shows START: tftp

pid=8144 from=192.168.242.3, which is as expected.

*scratches head* Hmm. Weird.

I am going to increase the logging level for tftpd and see what I get.

Good, hopefully something useful comes out of that! If you are not getting enough info, you might want to run a traffic dump: Run this as root on the client side: tcpdump -n -nn -s 1500 -X host 192.168.242.XXX

Where XXX is the last octet of the IP address of your TFTP server. That command will show *all* traffic between the client and the server. So if there is other traffic going between the hosts, you will see that too. To clean that up use something like this:

tcpdump -n -nn -s 1500 -X host 192.168.242.XXX and not port 22 and not port 80

The above command will get rid of any SSH and web traffic. Do not try to cut down traffic by just looking at port 69 traffic. TFTP only uses that in the first two packets or so, after that it runs on high ports. Just keep adding on "and not port YYY" until you have clean output. Since TFTP traffic is all in the clear, it is fairly easy to understand.

Mike

chrism@imntv.com wrote:

Mark Snyder wrote:

...

tftp keeps timing out when I try to transfer files. I intend to use tftp with G4U to clone a standard workstation. I am testing it between two Dell poweredge servers running CentOS 4.3. "chkconfig --list |grep tftp" shows tftp up and running on both boxes. When connected "tftp>status" shows it is talking to the other box "tptp>trace" shows "sent WRQ <file=slavelit, mode=netascii>" and ends with Transfer timed out.

I have tftp is being run under xinetd.

I have modified /etc/xinetd.d/tftpd as follows:

server_args -p -c -U 002 -u install -s /tster

I have setup a user install, set read/write privileges on /tster which is owned by install

Not sure what else I need to do to get this working, any suggestions would be appreciated

Have you checked the usual culprits? SELINUX or iptables? Try disabling them one at a time and see if the bad behavior disappears.

both are disabled, but it was a good thought.

Cheers,

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos