[jira] [Created] (NET-410) Apache Commons TFTP does not handle RFC 783 retransmits.

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

[jira] [Created] (NET-410) Apache Commons TFTP does not handle RFC 783 retransmits.

Gilles (Jira)
Apache Commons TFTP does not handle RFC 783 retransmits.
--------------------------------------------------------

                 Key: NET-410
                 URL: https://issues.apache.org/jira/browse/NET-410
             Project: Commons Net
          Issue Type: Bug
          Components: TFTP
    Affects Versions: 3.0, 2.2
         Environment: Sun/Oracle JRE 6 update 20
            Reporter: Chuck Wolber


org.apache.commons.net.tftp.TFTPClient

When a packet fails to be received,the looping logic in TFTPClient contains an unlabeled "continue" in the TFTPTimeout blocks. This causes TFTPClient to go back to the listening state in the innermost loop, rather than the sendPacket label in the outermost loop (which will cause a resend of the missing packet).

Note: This issue is not as simple as adding the _sendPacket label to the continue statement in the TFTPTimeout blocks. Doing so will expose the code to the Sorcerer's Apprentice Syndrome as defined in RFC 1123 section 4.2.3.1

--
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-410) Apache Commons TFTP does not handle RFC 783 retransmits.

Gilles (Jira)

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

Chuck Wolber updated NET-410:
-----------------------------

    Description:
org.apache.commons.net.tftp.TFTPClient

When a packet fails to be received, the looping logic in TFTPClient contains an unlabeled "continue" in the TFTPTimeout blocks. This causes TFTPClient to go back to the listening state in the innermost loop, rather than the sendPacket label in the outermost loop (which will cause a resend of the missing packet).

Note: This issue is not as simple as adding the _sendPacket label to the continue statement in the TFTPTimeout blocks. Doing so will expose the code to the Sorcerer's Apprentice Syndrome as defined in RFC 1123 section 4.2.3.1

  was:
org.apache.commons.net.tftp.TFTPClient

When a packet fails to be received,the looping logic in TFTPClient contains an unlabeled "continue" in the TFTPTimeout blocks. This causes TFTPClient to go back to the listening state in the innermost loop, rather than the sendPacket label in the outermost loop (which will cause a resend of the missing packet).

Note: This issue is not as simple as adding the _sendPacket label to the continue statement in the TFTPTimeout blocks. Doing so will expose the code to the Sorcerer's Apprentice Syndrome as defined in RFC 1123 section 4.2.3.1


> Apache Commons TFTP does not handle RFC 783 retransmits.
> --------------------------------------------------------
>
>                 Key: NET-410
>                 URL: https://issues.apache.org/jira/browse/NET-410
>             Project: Commons Net
>          Issue Type: Bug
>          Components: TFTP
>    Affects Versions: 2.2, 3.0
>         Environment: Sun/Oracle JRE 6 update 20
>            Reporter: Chuck Wolber
>
> org.apache.commons.net.tftp.TFTPClient
> When a packet fails to be received, the looping logic in TFTPClient contains an unlabeled "continue" in the TFTPTimeout blocks. This causes TFTPClient to go back to the listening state in the innermost loop, rather than the sendPacket label in the outermost loop (which will cause a resend of the missing packet).
> Note: This issue is not as simple as adding the _sendPacket label to the continue statement in the TFTPTimeout blocks. Doing so will expose the code to the Sorcerer's Apprentice Syndrome as defined in RFC 1123 section 4.2.3.1

--
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-410) Apache Commons TFTP does not handle RFC 783 retransmits.

Gilles (Jira)
In reply to this post by Gilles (Jira)

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

Chuck Wolber updated NET-410:
-----------------------------

    Description:
org.apache.commons.net.tftp.TFTPClient

When a packet fails to be received, the looping logic in TFTPClient contains an unlabeled "continue" in the TFTPTimeout blocks. This causes TFTPClient to go back to the listening state in the innermost loop, rather than the _sendPacket label in the outermost loop (which will cause a resend of the missing packet).

This issue should be resolved before implementing NET-412.

  was:
org.apache.commons.net.tftp.TFTPClient

When a packet fails to be received, the looping logic in TFTPClient contains an unlabeled "continue" in the TFTPTimeout blocks. This causes TFTPClient to go back to the listening state in the innermost loop, rather than the sendPacket label in the outermost loop (which will cause a resend of the missing packet).

Note: This issue is not as simple as adding the _sendPacket label to the continue statement in the TFTPTimeout blocks. Doing so will expose the code to the Sorcerer's Apprentice Syndrome as defined in RFC 1123 section 4.2.3.1


> Apache Commons TFTP does not handle RFC 783 retransmits.
> --------------------------------------------------------
>
>                 Key: NET-410
>                 URL: https://issues.apache.org/jira/browse/NET-410
>             Project: Commons Net
>          Issue Type: Bug
>          Components: TFTP
>    Affects Versions: 2.2, 3.0
>         Environment: Sun/Oracle JRE 6 update 20
>            Reporter: Chuck Wolber
>
> org.apache.commons.net.tftp.TFTPClient
> When a packet fails to be received, the looping logic in TFTPClient contains an unlabeled "continue" in the TFTPTimeout blocks. This causes TFTPClient to go back to the listening state in the innermost loop, rather than the _sendPacket label in the outermost loop (which will cause a resend of the missing packet).
> This issue should be resolved before implementing NET-412.

--
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] [Resolved] (NET-410) Apache Commons TFTP does not handle RFC 783 retransmits.

Gilles (Jira)
In reply to this post by Gilles (Jira)

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

Sebb resolved NET-410.
----------------------

       Resolution: Fixed
    Fix Version/s: 3.1
   

> Apache Commons TFTP does not handle RFC 783 retransmits.
> --------------------------------------------------------
>
>                 Key: NET-410
>                 URL: https://issues.apache.org/jira/browse/NET-410
>             Project: Commons Net
>          Issue Type: Bug
>          Components: TFTP
>    Affects Versions: 2.2, 3.0
>         Environment: Sun/Oracle JRE 6 update 20
>            Reporter: Chuck Wolber
>             Fix For: 3.1
>
>
> org.apache.commons.net.tftp.TFTPClient
> When a packet fails to be received, the looping logic in TFTPClient contains an unlabeled "continue" in the TFTPTimeout blocks. This causes TFTPClient to go back to the listening state in the innermost loop, rather than the _sendPacket label in the outermost loop (which will cause a resend of the missing packet).
> This issue should be resolved before implementing NET-412.

--
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