Fluxos de bit de retorno de carro e de alimentação de linha em um arquivo binário durante o upload de TFTP no modo ASCII

Question

No caso de TFTP, pode-se escolher entre o modo "ASCII" ou "octeto". Como entendi, 00001010 (nova linha) ou 00001101 (retorno de carro) fluxos de bits em um arquivo binário receberão algum tipo de tratamento especial no modo ASCII? No entanto, criei um arquivo contendo esses caracteres:

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:~# 

.. e quando eu fiz upload desse arquivo do cliente TFTP para o servidor TFTP usando os modos "octeto" e "netascii", o arquivo atingiu o servidor TFTP na mesma condição e tinha exatamente o mesmo conteúdo:

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

Eu fiz algo errado? Ou como o modo ASCII deve manipular os dados binários?

    

Answer 1

O TFTP usa mecanismos semelhantes ao telnet para transmitir ASCII. Ele segue as regras estabelecidas na especificação NVT . Portanto, os marcadores de fim de linha são terminados com <cr><lf> e, se você quiser enviar um <cr> real, isso será traduzido como <cr><nul> .

hexdumping um arquivo que criei:

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

No entanto, na transmissão por meio de tftp (obtido de um tcpdump -X ):

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

Observe como a sequência <cr><lf> foi convertida em <cr><nul><cr><lf> .

Quando difundo os resultados do arquivo local e remoto, acabo com o mesmo arquivo. Isso ocorrerá porque a sequência <cr><nul> será retornada para <cr> e o formato local (em unix) para uma nova linha será <lf> e, assim, o <cr><lf> será transformado em <lf> e o arquivo original será transmitido é recebido. Não tenho tanta certeza sobre como um servidor tftp do DOS lidaria com a sequência <cr><nul><cr><lf> , tenho a sensação de que pode atrapalhar a saída para ter um% extra<cr> ( <cr><nul> se torna <cr> e <cr><lf> se torna <cr><lf> ), especialmente considerando os estados da RFC:

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

Referências

TFTP RFC, RFC1350 e o Especificação Telnet NVT .