tftpをxinetd経由で使うときにちょっとハマった話

寒いです、今年の冬はちょっとおかしい. 今朝の気温が氷点下６℃とは…
ただ昔も冬の間数回はそのくらいの気温になったんで、昔に戻ったということですかねぇ
昔に比べて家の断熱性能や暖房器具の性能が上がっているし、ヒートテックなんて快適なものもありますから、その当時とは比べ物にならないくらい過ごしやすいです…

今朝起きたら下弦の月が綺麗だったので極寒の中で写真撮ってみたらピントが全然だめでちょっとがっかりしているところ…

さて、仕事でちょっとばかし「ふーん」と思うような発見があって、それを書いてみます.
小ネタです(笑)

tftp

組み込み系のプログラミングを仕事としてやってます. プログラミングの対象となる機器の試作段階ではプログラムの更新がやりやすいように起動時に開発環境のLinux PCからプログラムをダウンロードしてbootするようにしてます. そのプログラムのダウンロードにtftp(Trivial File Transfer Protocol)プロトコルを使います.

なぜか接続できない

いっしょに仕事している方から「設定は正しいはずなんだけどプログラムがダウンロードされない」と相談をうけちょっと見てみました.
いろいろ見てみたところ、Linux PCと対象機器のネットワークインタフェースにIPアドレスが設定されLink UPされているので問題無いようです, Linux PC で arp tableを見ると対象機器のMACアドレスが表示されているのでARPプロトコルは問題なし.

いろいろ調べてみた

Linux PC 側でtcpdumpでパケットをキャプチャしてみると対象機器からtftpでファイル取得の要求は来ているけど Linux PCが ICMP destination port unreachableを返してる,すなわちUDP 69ポートがふさがっている、ということからtftpサーバーが起動していないことがわかりました.

tftp サーバーは直接起動せずセキュリティ対策のため xinetd を経由して起動するようにしてます. /etc/xinetd.d/tftp を見ても問題なさそうに見えます.

service tftp
{
protocol=udp
port=69
socket_type=dgram
wait=yes
user=nobody
server=/usr/sbin/in.tftpd
server_args=/tftpboot
disable=no
}

ログを再確認

原点に立ち戻ってLinux PC 側のログを再度確認してみましたら

Attribute protocol needs a space before operator

とあるじゃないですか！
そして/etc/xinetd.d/tftp を以下のように修正して, xinetd を再起動すると見事繋がりました！

service tftp
{
 protocol        = udp
 port            = 69
 socket_type     = dgram
 wait            = yes
 user            = nobody
 server          = /usr/sbin/in.tftpd
 server_args     = /tftpboot
 disable         = no
}

つまり = などのoprator の前後には空白が必要、ということ. これはman コマンドにも書いてなかったなぁ…ということで、何かのお役に立てれば幸いです…はい