commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Armbrust (JIRA)" <>
Subject [jira] Commented: (NET-181) tftp client limited to ~32 MB file sizes
Date Mon, 07 Jan 2008 23:02:38 GMT


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

View raw message