Skip to Main Content
IBM Power Ideas Portal

This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Is a defect
Workspace IBM i
Categories Networking
Created by Guest
Created on Nov 17, 2021

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

Please implement rolling to 0, allowing client interopatibility.

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

Use Case:

When a file more than 32megabytes is uploaded to the TFTP server using common clients, the transfer crashes producing a truncated file.

Idea priority Medium
  • Guest
    Aug 8, 2022

    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



    root@freebsd:~ # 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

  • Guest
    Jul 27, 2022
    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
  • Guest
    Jul 11, 2022

    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?

  • Guest
    Jan 26, 2022

    Please open a PMR to discuss this issue further.

    BTW, I searched the cisco website and this page 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 ?

  • Guest
    Jan 25, 2022

    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:// (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

  • Guest
    Jan 21, 2022

    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.

  • Guest
    Dec 17, 2021

    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.