TFTP server, please allow modern TFTP options allowing more than 32MB files

IBM does not intend to provide a solution to this Idea at this time, so it is being closed.
Thank you for taking the time to submit your Idea.
After careful consideration, we know that we cannot deliver your requested enhancement soon,
so it is being declined.
However, your Idea does align with the future strategy of our product and we believe it may have
future value, so we will add it to an internal list for us to keep in mind for the future.

IBM Power Systems Development

However, I have now understood and identified the problem, it was evident switching tftp client and using a tftp client from the unix FreeBSD distribution that is clear about the problem being one of the most verbose tools and with most options available (**).

MOST if not all of the TFTP servers in the market supports what is called “rollback to 0” (personally, the only TFTP server that I’ve encountered not supporting it is the IBMi one…).

Basically once you reach block number 65535 MOST if not ALL tftp clients in the market restart the block numbering from 0 thus letting the transfer proceed, but evidently this crashes/hangs the IBMi TFTP process server that doesn’t like the behavior.

This can be considered a non-standard prescribed but a common use option, virtually seen in any on the field device.

If I increment manually the block KB size on the unix tftp client (one of the few clients that allow it), I confirm that the file > 32MB is transferred successfully to IBMi.

Thus I think the options here basically are:

• IBM strives for full adherence to what it is prescribed by the RFC standard so refuses to interoperate with basically common TFTP clients implementations in the world that usually defaults rolling back to 0

• IBM implements an option in CHGTFTPA, that says “(non standard) Supports rolling to 0 clients for compatibility” *YES *NO

I hope that clarifies

thanks

(**)

root@freebsd:~ # tftp
tftp>
tftp> help
Commands may be abbreviated.  Commands are:

connect         connect to remote tftp
mode            set file transfer mode
put             send file
get             receive file
quit            exit tftp
verbose         toggle verbose mode
status          show current status
binary          set mode to octet
ascii           set mode to netascii
rexmt           set per-packet retransmission timeout[-]
timeout         set total retransmission timeout
trace           enable 'debug packet'[-]
debug           enable verbose output
blocksize       set blocksize[*]
blocksize2      set blocksize as a power of 2[**]
rollover        rollover after 64K packets[**]
options         enable or disable RFC2347 style options
help            print help information
packetdrop      artificial packetloss feature
windowsize      set windowsize[*]
?               print help information

[-] : You shouldn't use these ones anymore.
[*] : RFC2347 options support required.
[**] : Non-standard RFC2347 option.
tftp> rollover
Support for the rollover options is enabled.
Block rollover will be to block 0.

The following rollover options are available:
        rollover 0      : rollover to block zero (default)
        rollover 1      : rollover to block one
        rollover never  : do not support the rollover option
        rollover none   : do not support the rollover option

There are currently no PTFs built for an issue related to this. Please open a PMR if you are seeing a failure with this functionality, so that analysis of the failure can take place.

IBM Power Systems Development

On my particual device used for the test the segment size it cannot be set (Cisco ASA). But it worked sending to other TFTP servers as is without any problems.

I see anyway that this was marked as a defect indeed, so I think it is already under analysis by IBM and no discussion is required. Was it already corrected in a PTF maybe?

Please open a PMR to discuss this issue further.

BTW, I searched the cisco website and this page
https://www.cisco.com/c/en/us/support/docs/wireless/5760-wireless-lan-controller/117636-technote-tftpfile-00.html might help.
According to this page, the default blksize is 512 and can be configured using command "ip tftp blocksize ***"
command to check current config value: ip tftp blocksize ?

Thanks for the answer.
I've changed the TFTP to the maximum block size allowed and restarted the TFTP server on IBMi.
But, when I try to write a "big" file to the IBMi TFTP server from a recent Cisco device, the client crashes at 33550336 bytes.
It can of course transfer successfully files of size less than the aforementioned number.

----
Destination filename? test1.bin
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
%Error writing tftp://192.168.100.200/test1.bin (Timed out during transfer)
33550336 bytes copied in 39.0 secs (860265 bytes/sec)
----

The *same* client with the same command can write successfully the whole "big" file when targeted to a different TFTP server (hosted on Windows, Solarwinds TFTP).

Reading the server joblog running with user QTFTP, it logs an error TCP5646 regarding "internal TFTP protocol error" at the source QTODSCM1.c at line 7357.

So being truncated at 33550336 I thought it was a limit of a forced 512 sized segment somewhere (not respecting the parametrization in CHGTFTPA).

But at this point you suggested that the TFTP server can handle bigger files honoring the segment szie, so at this point I think the fault / incompatibility lies somewhere so in case I will open a assistance request treating this as a bug.

thanks, bye

IBM i already supported the RFC 2348. Per RFC 2348, the max block size can be negotiated between tftp client and server. The max block size can be configured by CHGTFTPA MAXBLKSIZE. The default size is 1024, and the limit would be 1024*65535 blocks = 64M. The maximum MAXBLKSIZE is 65464 and the limit would be near 4G (65464*65535) bytes.

To transfer large file with TFTP,
1. please change the MAXBLKSIZE with CL CHGTFTPA
2. please make sure the tftp client size supports RFC 2348. Of course this RFC was requested in 1998. Most of TFTP client should follow.

Please let me know whether this address your business needs.

Thank you for taking the time to submit this request. IBM has received the requirement and is evaluating it. IBM will provide a response after evaluation is complete.