PXE-E32: TFTP open timeout

Peter Rathlev peter at rathlev.dk
Wed Aug 6 07:10:34 UTC 2014

On Mon, 2014-08-04 at 09:11 -0700, Mahmood N wrote:
> When the client starts, it receives the following error
> PXE-E32: TFTP open timeout
> I don't know if that error is related to dhcpd or xinetd.
> Any idea is welcomed.

This is not related to dhcpd and thus probably OT for this list. But
since it's peripherally related to DHCP... :-)

First check if xinetd is actually listening for the request:

# netstat -nlp | fgrep ":69 "
udp     0       0*       2614/xinetd

If not (no output) then try to restart xinetd and see if it helps.

Next up, check your logs to see if tftpd actually sees the requests.
Look for "tftpd" (or "in.tftpd") tagged messages in /var/log/messages or
where ever you have it to log. You should see some lines with "RRQ"
messages. If you see these they might give you a hint, e.g. file not
found or permission denied. (Our tftpd on CentOS 5 doesn't always log
RRQs though, so lack of messages isn't necessarily a problem.)

Lastly, and probably the most probable cause, check to see if you might
have a firewall blocking the traffic on the server. First see if the
netfilter modules are loaded:

# lsmod | fgrep table
iptable_filter   36161 1 
ip_tables        55457 1 iptable_filter
ip6table_filter  36033 1 
ip6_tables       50177 1 ip6table_filter
x_tables         50505 6 ipt_REJECT,xt_state,ip_tables,ip6t_REJECT,xt_tcpudp,ip6_tables

If they are NOT loaded (i.e. empty output) then running the following
commands will actually load the modules. And you probably don't want

Otherwise run "iptables -t filter -L -v -n". Look for things that might
deny your request, or maybe look for the specific opening that needs to
be there. It's inbound port 69/udp as you probably know.

A tcpdump from the server (e.g. "tcpdump -i eth0 -nn host <device>")
might give you a clue. If the server answers "port unreachable" it
sounds like xinetd isn't correctly listening. If the server answers
"admin prohibited" or doesn't answer at all it might be a firewall. If
the server answers with UDP traffic of some kind the packet contents
might give a hint. Beware that TFTP doesn't necessarily answer on port
69/udp so you have to look at all traffic between the to machines.


More information about the dhcp-users mailing list