current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 1 down vote favorite

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 >> bfile
root@A58:~# xxd -b bfile
0000000: 00001010 00001101 01000001                             ..A
root@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?

share|improve this question

1 Answer 1

up vote 1 down vote

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.

References

TFTP RFC, RFC1350 and the Telnet NVT Specification.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.