[jira] [Created] (NET-412) Apache Commons TFTP implementation subject to Sorcerer's Apprentice Syndrome

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Created] (NET-412) Apache Commons TFTP implementation subject to Sorcerer's Apprentice Syndrome

ASF GitHub Bot (Jira)
Apache Commons TFTP implementation subject to Sorcerer's Apprentice Syndrome
----------------------------------------------------------------------------

                 Key: NET-412
                 URL: https://issues.apache.org/jira/browse/NET-412
             Project: Commons Net
          Issue Type: Bug
          Components: TFTP
    Affects Versions: 3.0, 2.2
         Environment: Java 6 patch 20
            Reporter: Chuck Wolber
            Priority: Critical


This is regarding the org.apache.commons.net.tftp.TFTPClient class.

In the sendFile() method, when a duplicate TFTP ACK is received, the "if (lastBlock == block)" section of code fails and control moves to the "else" statement. The else block checks to see if the ACK is for the previous DATA packet, and if so, sends control back to the _sendPacket label where the DATA packet is resent.

This is in direct violation of Sorcerer's Apprentice Syndrome as defined in RFC 1123 section 4.2.3.1:

"the sender (i.e., the side originating the DATA packets) must never resend the current DATA packet on receipt of a duplicate ACK"

The proper else block would look something like this:

{
    continue _receivePacket;
}

This enables the client to ignore the duplicated ACK and listen for ACK+1. If ACK+1 never comes in, the listener should timeout and attempt to resend the current data packet. As described in NET-410, the TFTP client also does not properly handle re-transmits either. It is recommended that this issue and NET-410 be implemented in tandem.





--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[jira] [Updated] (NET-412) Apache Commons TFTP implementation subject to Sorcerer's Apprentice Syndrome

ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/NET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb updated NET-412:
---------------------

    Description:
This is regarding the org.apache.commons.net.tftp.TFTPClient class.

In the sendFile() method, when a duplicate TFTP ACK is received, the "if (lastBlock == block)" section of code fails and control moves to the "else" statement. The else block checks to see if the ACK is for the previous DATA packet, and if so, sends control back to the _sendPacket label where the DATA packet is resent.

This is in direct violation of Sorcerer's Apprentice Syndrome as defined in RFC 1123 section 4.2.3.1:

"the sender (i.e., the side originating the DATA packets) must never resend the current DATA packet on receipt of a duplicate ACK"

The proper else block would look something like this:

{noformat}
{
    continue _receivePacket;
}
{noformat}

This enables the client to ignore the duplicated ACK and listen for ACK+1. If ACK+1 never comes in, the listener should timeout and attempt to resend the current data packet. As described in NET-410, the TFTP client also does not properly handle re-transmits either. It is recommended that this issue and NET-410 be implemented in tandem.





  was:
This is regarding the org.apache.commons.net.tftp.TFTPClient class.

In the sendFile() method, when a duplicate TFTP ACK is received, the "if (lastBlock == block)" section of code fails and control moves to the "else" statement. The else block checks to see if the ACK is for the previous DATA packet, and if so, sends control back to the _sendPacket label where the DATA packet is resent.

This is in direct violation of Sorcerer's Apprentice Syndrome as defined in RFC 1123 section 4.2.3.1:

"the sender (i.e., the side originating the DATA packets) must never resend the current DATA packet on receipt of a duplicate ACK"

The proper else block would look something like this:

{
    continue _receivePacket;
}

This enables the client to ignore the duplicated ACK and listen for ACK+1. If ACK+1 never comes in, the listener should timeout and attempt to resend the current data packet. As described in NET-410, the TFTP client also does not properly handle re-transmits either. It is recommended that this issue and NET-410 be implemented in tandem.





   

> Apache Commons TFTP implementation subject to Sorcerer's Apprentice Syndrome
> ----------------------------------------------------------------------------
>
>                 Key: NET-412
>                 URL: https://issues.apache.org/jira/browse/NET-412
>             Project: Commons Net
>          Issue Type: Bug
>          Components: TFTP
>    Affects Versions: 2.2, 3.0
>         Environment: Java 6 patch 20
>            Reporter: Chuck Wolber
>            Priority: Critical
>
> This is regarding the org.apache.commons.net.tftp.TFTPClient class.
> In the sendFile() method, when a duplicate TFTP ACK is received, the "if (lastBlock == block)" section of code fails and control moves to the "else" statement. The else block checks to see if the ACK is for the previous DATA packet, and if so, sends control back to the _sendPacket label where the DATA packet is resent.
> This is in direct violation of Sorcerer's Apprentice Syndrome as defined in RFC 1123 section 4.2.3.1:
> "the sender (i.e., the side originating the DATA packets) must never resend the current DATA packet on receipt of a duplicate ACK"
> The proper else block would look something like this:
> {noformat}
> {
>     continue _receivePacket;
> }
> {noformat}
> This enables the client to ignore the duplicated ACK and listen for ACK+1. If ACK+1 never comes in, the listener should timeout and attempt to resend the current data packet. As described in NET-410, the TFTP client also does not properly handle re-transmits either. It is recommended that this issue and NET-410 be implemented in tandem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Resolved] (NET-412) Apache Commons TFTP implementation subject to Sorcerer's Apprentice Syndrome

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/NET-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb resolved NET-412.
----------------------

       Resolution: Fixed
    Fix Version/s: 3.1
   

> Apache Commons TFTP implementation subject to Sorcerer's Apprentice Syndrome
> ----------------------------------------------------------------------------
>
>                 Key: NET-412
>                 URL: https://issues.apache.org/jira/browse/NET-412
>             Project: Commons Net
>          Issue Type: Bug
>          Components: TFTP
>    Affects Versions: 2.2, 3.0
>         Environment: Java 6 patch 20
>            Reporter: Chuck Wolber
>            Priority: Critical
>             Fix For: 3.1
>
>
> This is regarding the org.apache.commons.net.tftp.TFTPClient class.
> In the sendFile() method, when a duplicate TFTP ACK is received, the "if (lastBlock == block)" section of code fails and control moves to the "else" statement. The else block checks to see if the ACK is for the previous DATA packet, and if so, sends control back to the _sendPacket label where the DATA packet is resent.
> This is in direct violation of Sorcerer's Apprentice Syndrome as defined in RFC 1123 section 4.2.3.1:
> "the sender (i.e., the side originating the DATA packets) must never resend the current DATA packet on receipt of a duplicate ACK"
> The proper else block would look something like this:
> {noformat}
> {
>     continue _receivePacket;
> }
> {noformat}
> This enables the client to ignore the duplicated ACK and listen for ACK+1. If ACK+1 never comes in, the listener should timeout and attempt to resend the current data packet. As described in NET-410, the TFTP client also does not properly handle re-transmits either. It is recommended that this issue and NET-410 be implemented in tandem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira