☰

TFTP ASCII 模式上传时二进制文件中的回车换行比特流

tag-icon • tag-icon ftp text newlines tftp
TFTP ASCII 模式上传时二进制文件中的回车换行比特流

对于 TFTP，可以选择“ASCII”或“八位字节”模式。据我了解，二进制文件中的 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>。

十六进制转储我创建的文件：

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

然而，通过 tftp 传输（从 a 获得tcpdump -X）：

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

请注意序列如何<cr><lf>转换为<cr><nul><cr><lf>.

当我比较本地和远程文件的结果时，我最终得到相同的文件。这是因为<cr><nul>序列将被返回，<cr>并且换行符的本地格式（在unix下）是<lf>，因此<cr><lf>被转换成<lf>并且接收到传输的原始文件。我不太确定 DOS tftp 服务器如何处理该<cr><nul><cr><lf>序列，我有一种感觉，它可能会破坏输出以产生额外的<cr>（<cr><nul>变成<cr>和<cr><lf>变成<cr><lf>），特别是考虑到 RFC 状态：

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

参考

TFTP RFC、RFC1350和Telnet NVT 规范。

相关内容