PXE 引導期間的 TFTP 超時問題

在 CentOS 7 機器上設置 PXE 引導伺服器時，我遇到了一個奇怪的 TFTP 問題。如果沒有遇到超時問題，我無法從 TFTP 伺服器檢索任何文件。啟動過程到此為止，我正確地從 DHCP 伺服器獲得了 IP 地址和文件名。但是，當要從 TFTP 伺服器檢索引導文件時，會出現“TFTP 打開超時”消息。如果我從本地電腦手動建立到 PXE 伺服器的 TFTP 連接，我會立即訪問該伺服器。但如果我嘗試使用“get pxelinux.0”命令，我會收到另一條超時消息。我的防火牆設置正確，如果我完全關閉防火牆也沒有什麼區別。SeLinux 也被禁用。如果我在埠 69 上進行 tcpdump，我會收到以下消息：

12:34:33.477401 IP 172.16.1.202.ah-esp-encap > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:35.481131 IP 172.16.1.202.acp-port > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:39.490793 IP 172.16.1.202.msync > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:45.477712 IP 172.16.1.202.gxs-data-port > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:53.441801 IP 172.16.1.202.vrtl-vmf-sa > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:35:03.384065 IP 172.16.1.202.newlixengine > tools.dmz.tuxme.dk.tftp:  32 RRQ "pxelinux.0" octet blksize 1456
12:35:39.414843 IP 172.16.1.202.newlixconfig > tools.dmz.tuxme.dk.tftp:  32 RRQ "pxelinux.0" octet blksize 1456
12:36:51.422568 IP 172.16.1.202.tsrmagt > tools.dmz.tuxme.dk.tftp:  32 RRQ "pxelinux.0" octet blksize 1456
12:38:39.406732 IP 172.16.1.202.tpcsrvr > tools.dmz.tuxme.dk.tftp:  32 RRQ "pxelinux.0" octet blksize 1456

不幸的是，系統日誌沒有顯示任何有用的資訊：

Jan 15 13:13:19 tools xinetd[6993]: EXIT: tftp status=67 pid=7954 duration=0(sec)
Jan 15 13:13:21 tools xinetd[6993]: START: tftp pid=7955 from=172.16.1.202
Jan 15 13:13:21 tools in.tftpd[7955]: no user tftp: Success
Jan 15 13:13:21 tools xinetd[6993]: EXIT: tftp status=67 pid=7955 duration=0(sec)
Jan 15 13:13:25 tools xinetd[6993]: START: tftp pid=7956 from=172.16.1.202
Jan 15 13:13:25 tools in.tftpd[7956]: no user tftp: Success
Jan 15 13:13:25 tools xinetd[6993]: EXIT: tftp status=67 pid=7956 duration=0(sec)
Jan 15 13:13:31 tools xinetd[6993]: START: tftp pid=7957 from=172.16.1.202
Jan 15 13:13:31 tools in.tftpd[7957]: no user tftp: Success

/var/lib/tftpboot 目錄的權限是 0755。

這是我的設置文件：

/etc/xinetd.d/tftp:

service tftp
socket_type             = dgram
protocol                = udp
wait                    = yes
user                    = root
server                  = /usr/sbin/in.tftpd
server_args             = -c -v -u tftp -p -U 117 -s /var/lib/tftpboot
disable                 = no
per_source              = 11
cps                     = 100 2
flags                   = IPv4

看起來tcpdump輸出只包含請求，根本沒有任何響應。如果這是實際發生的情況，則預期會出現超時錯誤。

在server_argsxinetd 的 TFTP 配置行中，您有-u tftp. 這告訴in.tftpd以使用者身份執行tftp。鑑於此，記錄的這條消息in.tftpd可能很重要：

Jan 15 13:13:21 tools in.tftpd[7955]: no user tftp: Success

它說“沒有使用者 tftp”。使用者帳戶**是否實際存在於您的系統中？tftp

Success日誌消息末尾的 需要一點 C 程式知識才能理解。它可能來自一個極簡的錯誤處理函式，它可能只是呼叫perror()然後在退出之前進行任何必要的清理。

該perror()函式從其呼叫者那裡獲取一條消息，然後附加一條與errno變數的目前值相對應的標準錯誤消息。它旨在用於先前系統呼叫失敗的情況；自定義消息應該描述遇到錯誤時程序正在做什麼，然後標準消息應該闡明遇到的問題的類型。

但是，如果程序員使用他們的錯誤處理函式報告了一個以其他方式擷取的錯誤，標準錯誤消息部分將顯示為Success.

我的猜測是該in.tftpd過程開始於xinetd，準備切換到 user tftp，並發現這樣的使用者不存在。因此，該in.tftpd程序輸出該日誌消息並在沒有向客戶端發送任何內容的情況下終止。

結尾帶有誤導性“成功”的簡潔資訊是“如果你唯一的工具是錘子，你傾向於把一切都當作釘子”的舊概念的一個例子。在這種情況下，程序員可能在其輸出格式不太適合的情況下使用了他們唯一的錯誤處理功能。

此外，這些請求看起來有點奇怪：

12:34:33.477401 IP 172.16.1.202.ah-esp-encap > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:35.481131 IP 172.16.1.202.acp-port > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:39.490793 IP 172.16.1.202.msync > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:45.477712 IP 172.16.1.202.gxs-data-port > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0
12:34:53.441801 IP 172.16.1.202.vrtl-vmf-sa > tools.dmz.tuxme.dk.tftp:  27 RRQ "pxelinux.0" octet tsize 0

tsize 0表示客戶端期望 TFTP 傳輸文件大小總計為 0 字節。

您是否知道 UEFI PXE 規範（存在於 UEFI 2.3 版左右）要求 DHCP 伺服器告訴 PXE 客戶端它應該載入的文件的大小？如果您使用的是 ISC DHCP 伺服器，則所需的選項可以指定為

option boot-size <size value>; 

應該是引導文件的<size value>大小（以字節為單位）除以 512，然後向上取整。

引用自：https://unix.stackexchange.com/questions/494699