☰

TFTP ASCIIモードでアップロードするときのバイナリファイルのキャリッジリターンとラインフィードビットストリーム

tag-icon • tag-icon ftp text newlines tftp
TFTP ASCIIモードでアップロードするときのバイナリファイルのキャリッジリターンとラインフィードビットストリーム

TFTPでは、「ASCII」または「Octet」モードを選択できます。私が理解したのは、バイナリファイルの00001010（改行）または00001101（キャリッジリターン）ビットストリームがASCIIモードで何らかの特別な処理を受けますか？ただし、次の文字を含むファイルを作成しました。

root@A58:~# printf '\n' | xxd | xxd -r > bfile; printf '\r' | xxd | xxd -r >> bfile; printf 'A' | xxd | xxd -r >> bfile
root@A58:~# xxd -b bfile
0000000: 00001010 00001101 01000001                             ..A
root@A58:~#

.. "octet"モードと "netascii"モードを使用してTFTPクライアントからTFTPサーバーにこのファイルをアップロードすると、ファイルは同じ条件でTFTPサーバーに到達し、まったく同じ内容を持ちます。

T42 ~ # cmp /srv/tftp/reverse_ascii /srv/tftp/reverse_binary 
T42 ~ #

私は何が間違っていましたか？それとも、ASCIIモードがバイナリデータをどのように処理するのですか？

答え1

TFTP は Telnet と同様のメカニズムを使用して ASCII を送信します。で指定された規則に従います。NVT仕様。したがって、有効な行末マークはで終了します<cr><lf>。実際の行末マークを送信するには、<cr>に変換してください<cr><nul>。

私が作成したファイルの16進ダンプ：

00000000  0d 54 65 73 74 69 6e 67  33 0d 0a                 |.Testing3..|

ただし、tftpを介して送信する場合（から取得tcpdump -X）：

0x0020:  0d00 5465 7374 696e 6733 0d00 0d0a       ..Testing3....

シーケンス<cr><lf>は<cr><nul><cr><lf>。

ローカルファイルとリモートファイルの結果を比較すると、最終的に同じファイルが表示されます。これは<cr><nul>、シーケンスが返され、<cr>改行のデフォルト形式（unixで）がある<lf>ため、送信された元のファイルに<cr><lf>変換されて受信されるためです。 DOS tftpサーバーがそのシーケンスをどの<lf>ように処理するのかわかりません。特にRFC状態を考慮すると、追加を生成<cr><nul><cr><lf>するために出力が破損する可能性があります。<cr><cr><nul><cr><cr><lf><cr><lf>

A host which receives netascii mode data must translate the data to its own format.

引用する

TFTP RFC、RFC1350そしてTelnet NVT仕様。

関連情報