TFTP의 경우 "ASCII" 또는 "Octet" 모드를 선택할 수 있습니다. 내가 이해한 바로는 바이너리 파일의 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는 텔넷과 유사한 메커니즘을 사용하여 ASCII를 전송합니다. 에 지정된 규칙을 따릅니다.NVT 사양. 따라서 유효한 줄 끝 표시는 으로 종료됩니다 <cr><lf>. 실제 줄 끝 표시를 보내려면 <cr>으로 변환하세요 <cr><nul>.
내가 만든 파일의 16진수 덤프:
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>변환되어 수신되기 때문입니다 . DOS tftp 서버가 해당 시퀀스 를 <lf>어떻게 처리하는지 잘 모르겠습니다. 특히 RFC 상태를 고려할 때 추가 ( 와 ) 를 <cr><nul><cr><lf>생성하기 위해 출력을 손상시킬 수 있다는 느낌이 듭니다 .<cr><cr><nul><cr><cr><lf><cr><lf>
A host which receives netascii mode data must translate the data to its own format.
인용하다