虽然看起来一切配置都正确,但在 tftp 服务器上却出现“连接超时”,这可能是什么原因?

虽然看起来一切配置都正确,但在 tftp 服务器上却出现“连接超时”,这可能是什么原因?

我刚刚在工作中的 CentOS 6.6 机器上安装了一个 cobbler(带有 tftp/dhcp)服务器。我已将 tftp 配置为在 xinetd 下运行,conf 文件如下所示:

service tftp
{
        disable                 = no
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -B 1380 -v -s /var/lib/tftpboot
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}

当其中一台客户端 tftp 机器(将使用 cobbler 和 kickstart 进行安装)启动时,它会成功地从 dhcp 服务器接收一个 IP 地址,该地址来自“range dynamic-bootp”指令中配置的正确范围,/etc/dhcp/dhcpd.conf但是当它继续加载图像的阶段时,pxelinux.0它会挂起,然后超时并显示以下消息:

tftp://10.13.0.1/pxelinux.0........... Connection timed out (0x4c126035)
Could not load tftp://10.13.0.1/pxelinux.0: Connection timed out (0x4c125035)

我采取的故障排除步骤:

  1. 已验证 iptables 已停止。
  2. 验证 /var/lib/tftpboot 上的权限为 755。
  3. 已验证 SELINUX 已被禁用。
  4. 我运行tftp localhost后它连接成功了,但是当我尝试时却get file.txt出现同样的“连接超时”错误。

编辑#1:

[root@centolel tftpboot]# netstat -apn|grep -w 69
udp        0      0 0.0.0.0:69    0.0.0.0:*     13097/xinetd

我忘了提及日志中的内容..那是从运行中得到的tftp localhost

Jun 30 11:44:02 localhost xinetd[13097]: START: tftp pid=24348 from=127.0.0.1
Jun 30 11:44:02 localhost xinetd[13097]: EXIT: tftp status=1 pid=24348 duration=0(sec)
Jun 30 11:44:07 localhost xinetd[13097]: START: tftp pid=24383 from=127.0.0.1
Jun 30 11:44:07 localhost xinetd[13097]: EXIT: tftp status=1 pid=24383 duration=0(sec)

从远程 tftp 机器:

Jun 30 11:45:56 localhost xinetd[13097]: START: tftp pid=25099 from=10.13.0.101
Jun 30 11:45:56 localhost xinetd[13097]: EXIT: tftp status=1 pid=25099 duration=0(sec)
Jun 30 11:46:00 localhost xinetd[13097]: START: tftp pid=25112 from=10.13.0.101
Jun 30 11:46:00 localhost xinetd[13097]: EXIT: tftp status=1 pid=25112 duration=0(sec)

任何想法可能是什么原因导致超时或如何解决?

答案1

守护进程在启动时意外死亡(status=1)。

看起来tftpd您使用的参数不适合当前tftp版本。从 shell 运行守护进程已将此问题纳入视野,您已使参数server_args对当前守护进程有意义,现在一切正常。

相关内容