質問: ipv4
回答: tcpdumpの出力には要求のみが含まれ、応答はまったく含まれていないようです。これが実際に起こっていることである場合、タイムアウトエラーが予想されます。xinetdのtftp構成の_server_args_行には、_-u tftp_があります。これは、_in.tftpd_にユーザーtftpとして実行するように指示します。それを考慮して、_in.tftpd_によってログに記録されたこのメッセージは重要かもしれません:_jan 15 13:13:21 tools in.tftpd[7955]: no user tftp: success _「nousertftp」と表示されます。 tftpユーザーアカウントは実際にシステムに存在しますか?ログメッセージの最後にあるsuccessを理解するには、cプログラミングの知識が少し必要です。これは、おそらくperror()を呼び出して、終了する前に必要なクリーンアップを実行する、最小限のエラー処理関数に由来する可能性があります。perror()関数は、呼び出し元からメッセージを受け取り、errno変数の現在の値に対応する標準エラーメッセージを追加します。以前のシステムコールが失敗した状況で使用するように設計されています。カスタムメッセージは、エラーが発生したときにプログラムが何をしていたかを説明する必要があり、標準メッセージは、発生した問題のタイプを明確にする必要があります。ただし、プログラマーがエラー処理機能を使用して、他の方法でキャッチされたエラーを報告した場合、標準のエラーメッセージ部分はsuccessと表示されます。私の推測では、_in.tftpd_プロセスはxinetdによって開始され、ユーザー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_は、クライアントが合計0バイトのファイルサイズのtftp転送を予期していることを示します。uefi pxe仕様は、uefiバージョン2.3程度に存在していたため、dhcpサーバーがpxeクライアントにロードする予定のファイルのサイズを通知する必要があることをご存知ですか? isc dhcpサーバーを使用している場合、必要なオプションは次のように指定できます。_option boot-size <size value>; __<size value>_は、バイト単位のブートファイルのサイズを512で割ってから、切り上げます。