tftp upload doesn't convert LF to CRLF for ;mode=netascii

[m-shibata]

I did this

# 1. create test file using LF as newline
$ echo -e "abc\ndef" > ~/test
$ hd ~/test
00000000  61 62 63 0a 64 65 66 0a                           |abc.def.|
00000008

# 2. upload file via tftp with ascii
$ LD_LIBRARY_PATH=/usr/local/lib curl -T ~/test "tftp://tftp.lxd/test;mode=ascii"

# 3. check sent packet by curl
$ tcpdump -r ~/test.pcap -XXX
reading from file /home/ubuntu/test.pcap, link-type EN10MB (Ethernet), snapshot length 262144
10:24:09.890720 IP6 curl.lxd.60800 > tftp.lxd.tftp: TFTP, length 46, WRQ "test" netascii tsize 8 blksize 512 timeout 6
        0x0000:  0016 3e90 9dbd 0016 3ec8 1158 86dd 600e  ..>.....>..X..`.
        0x0010:  2b74 0036 1140 fd42 0bb5 fbbe ed8d 0216  +t.6.@.B........
        0x0020:  3eff fec8 1158 fd42 0bb5 fbbe ed8d 0216  >....X.B........
        0x0030:  3eff fe90 9dbd ed80 0045 0036 136b 0002  >........E.6.k..
        0x0040:  7465 7374 006e 6574 6173 6369 6900 7473  test.netascii.ts
        0x0050:  697a 6500 3800 626c 6b73 697a 6500 3531  ize.8.blksize.51  <- should  be tsize to 0x10 or 0
        0x0060:  3200 7469 6d65 6f75 7400 3600            2.timeout.6.
10:24:09.891971 IP6 tftp.lxd.52698 > curl.lxd.60800: UDP, length 32
        0x0000:  0016 3ec8 1158 0016 3e90 9dbd 86dd 6008  ..>..X..>.....`.
        0x0010:  9345 0028 1140 fd42 0bb5 fbbe ed8d 0216  .E.(.@.B........
        0x0020:  3eff fe90 9dbd fd42 0bb5 fbbe ed8d 0216  >......B........
        0x0030:  3eff fec8 1158 cdda ed80 0028 135d 0006  >....X.....(.]..
        0x0040:  7473 697a 6500 3800 626c 6b73 697a 6500  tsize.8.blksize.
        0x0050:  3531 3200 7469 6d65 6f75 7400 3600       512.timeout.6.
10:24:09.892022 IP6 curl.lxd.60800 > tftp.lxd.52698: UDP, length 12
        0x0000:  0016 3e90 9dbd 0016 3ec8 1158 86dd 600c  ..>.....>..X..`.
        0x0010:  afab 0014 1140 fd42 0bb5 fbbe ed8d 0216  .....@.B........
        0x0020:  3eff fec8 1158 fd42 0bb5 fbbe ed8d 0216  >....X.B........
        0x0030:  3eff fe90 9dbd ed80 cdda 0014 1349 0003  >............I..
        0x0040:  0001 6162 630a 6465 660a                 ..abc.def.       <- should be "0x0a" to "0x0d 0x0a"
10:24:09.892086 IP6 tftp.lxd.52698 > curl.lxd.60800: UDP, length 4
        0x0000:  0016 3ec8 1158 0016 3e90 9dbd 86dd 6008  ..>..X..>.....`.
        0x0010:  9345 000c 1140 fd42 0bb5 fbbe ed8d 0216  .E...@.B........
        0x0020:  3eff fe90 9dbd fd42 0bb5 fbbe ed8d 0216  >......B........
        0x0030:  3eff fec8 1158 cdda ed80 000c 1341 0004  >....X.......A..
        0x0040:  0001

I expected the following

The LF line ending code is expected to be converted to CRLF before transmission and then converted to the appropriate line ending code on the server side.

However, curl sends LF as is in netascii mode, so it cannot convert the line ending code.

RFC 1350

Three modes of transfer are currently supported: netascii (This is ascii as defined in "USA Standard Code for Information Interchange" [1] with the modifications specified in "Telnet Protocol Specification" [3].)

RFC 854

  The sequence "CR LF", as defined, will cause the NVT to be
  positioned at the left margin of the next print line (as would,
  for example, the sequence "LF CR").  However, many systems and
  terminals do not treat CR and LF independently, and will have to
  go to some effort to simulate their effect.  (For example, some
  terminals do not have a CR independent of the LF, but on such
  terminals it may be possible to simulate a CR by backspacing.)
  Therefore, the sequence "CR LF" must be treated as a single "new
  line" character and used whenever their combined action is
  intended; the sequence "CR NUL" must be used where a carriage
  return alone is actually desired; and the CR character must be
  avoided in other contexts.  This rule gives assurance to systems
  which must decide whether to perform a "new line" function or a
  multiple-backspace that the TELNET stream contains a character
  following a CR that will allow a rational decision.

curl/libcurl version

$ LD_LIBRARY_PATH=/usr/local/lib curl --version
curl 8.6.0-DEV (x86_64-pc-linux-gnu) libcurl/8.6.0-DEV
Release-Date: [unreleased]
Protocols: dict file ftp gopher http imap ipfs ipns mqtt pop3 rtsp smtp telnet tftp
Features: alt-svc AsynchDNS IPv6 Largefile threadsafe UnixSockets
$ git log --oneline -1
8edcfedc1 (HEAD -> master, origin/master, origin/HEAD, master) ftp: use memdup0 to store the OS from a SYST 215 response

operating system

Ubuntu 22.04 LTS

[bagder]

I consider this a missing feature/enhancement more than a bug really. No one has requested this before.

[bagder]

Note that according to RFC 3617, the URL should be tftp://tftp.lxd/test;mode=netascii. There are two modes defined: netascii and octet.