[
https://issues.apache.org/jira/browse/NET-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556755#action_12556755
]
Dan Armbrust commented on NET-181:
----------------------------------
In my TFTP Server, simply wrapping the block number worked. So yes, I think it
is just that simple. That said, I would have felt better if I could have found
an RFC that said that wrapping the block number is expected practice... My only
confirmation was sampling 1 other tftp client, to see what it did.
I didn't look through the tftp client source in detail to see if there would be
any negative side-effects to wrapping the block number, at a glance, it didn't
look like there would be.
> tftp client limited to ~32 MB file sizes
> ----------------------------------------
>
> Key: NET-181
> URL: https://issues.apache.org/jira/browse/NET-181
> Project: Commons Net
> Issue Type: Improvement
> Environment: All
> Reporter: Dan Armbrust
> Priority: Minor
>
> I just noticed that the TFTPClient class does not support a block wraparound
> - hence, when the block number exceeds the max allowed by the rfc (65535) -
> about a 32 mb file - bad things will happen.
> I can't find any rfc that specifies how the wraparound is supposed to occur,
> but this wiki page mentions it:
> http://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol
> And I am working on implementing a TFTPServer - and in my tests with the tftp
> client that is shipped with fedora, I have determined that that tftp client
> expects the next block number after 65535 to be 0.
> So it appears that the TFTPClient should wrap its block number so that it
> properly supports larger files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
