In case of TFTP, one can choose between ASCII or octet mode. As I have understood, 00001010(new-line) or 00001101(carriage return) bit streams in a binary file will get some sort of special treatment in ASCII mode? However, I created a file containing those characters:root@A58:~# printf '\n' | xxd | xxd -r > bfile; printf '\r' | xxd | xxd -r >> bfile; printf 'A' | xxd | xxd -r >> bfileroot@A58:~# xxd -b bfile0000000: 00001010 00001101 01000001                             ..Aroot@A58:~# ..and when I uploaded this file from TFTP client to TFTP server using both octet and netascii modes, the file reached the TFTP server in same condition and had exactly the same content:T42 ~ # cmp /srv/tftp/reverse_ascii /srv/tftp/reverse_binary T42 ~ # Did I do something wrong? Or how should ASCII mode mangle the binary data?
Carriage Return and Line Feed bit streams in a binary file during TFTP upload in ASCII mode
ftp;text;newlines;tftp
TFTP uses similar mechanisms as telnet for transmitting ASCII. It follows the rules set out in the NVT specification. So effectively end-of-line markers are terminated with <cr><lf>, and if you want to send an actual <cr> then this is translated to <cr><nul>.hexdumping a file I created:00000000  0d 54 65 73 74 69 6e 67  33 0d 0a                 |.Testing3..|However on transmission over tftp (got from a tcpdump -X):0x0020:  0d00 5465 7374 696e 6733 0d00 0d0a       ..Testing3....Note how the <cr><lf> sequence has been converted to <cr><nul><cr><lf>.When I diff the results of the local and remote file, I end up with the same file. This will be because the <cr><nul> sequence will be returned back to <cr> and the local format (under unix) for a newline is <lf> and so the <cr><lf> is turned into <lf> and the original file as transmitted is received. I'm not so sure on how a DOS tftp server would handle the <cr><nul><cr><lf> sequence, I have a feeling it may mangle the output to have an extra <cr> (<cr><nul> becomes <cr> and <cr><lf> becomes <cr><lf>), especially given the RFC states:A host which receives netascii mode data must translate the data to its own format. ReferencesTFTP RFC, RFC1350 and the Telnet NVT Specification.