Потоки бит каретки и поток строки в двоичном файле во время загрузки TFTP в режиме ASCII

В случае TFTP можно выбрать режим «ASCII» или «октет». Как я понял, битовые потоки 00001010 (new-line) или 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:~# 

… и когда я загрузил этот файл из TFTP-клиента на TFTP-сервер, используя режимы «октет» и «нетасция», файл достиг TFTP-сервера в том же состоянии и имел точно такой же контент:

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

Я сделал что-то не так? Или как должен режим ASCII искажать двоичные данные?

One Solution collect form web for “Потоки бит каретки и поток строки в двоичном файле во время загрузки TFTP в режиме ASCII”

TFTP использует аналогичные механизмы, такие как telnet для передачи ASCII. Он следует правилам, изложенным в спецификации NVT . Таким образом, эффективные маркеры конца строки завершаются с помощью <cr><lf> , и если вы хотите отправить фактический <cr> то это будет переведено на <cr><nul> .

hexdumping файл, который я создал:

 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> превращается в <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 .

  • Загрузка через локальную сеть с помощью uboot
  • Не удалось установить tftpd-hpa
  • копировать файлы с сервера tftp
  • Установка TFTP-сервера без Интернета
  • Загрузка структуры каталогов с TFTP-сервера
  • TFTP «put» работает с файлами в pwd, но с ошибками с абсолютными путями
  • передача tftp болезненно медленная
  • Загрузка PXE Live CD
  • Передача файла Tftp через последовательный порт
  • Автоматическая установка Centos7 (PXE) заканчивается при загрузке в live-DVD-вход
  • iptables: правила для сервера tftp
  • Linux и Unix - лучшая ОС в мире.