Bugs item #3057696, was opened at 2010-09-01 21:32
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3057696&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: TFTP
Group: bad behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tim Newsome (timnewsome)
Assigned to: Daniel Stenberg (bagder)
Summary: 32MB+ tftp upload fails with tftpd-hpa

Initial Comment:
This is a continuation of bug 2848436, but I couldn't figure out how to add a comment there.
tftpd-hpa has a bug that makes uploads of 32MB+ files fail when TFTP options are sent to the server. Since that is the tftp server bundled with most (all?) Linux distributions I think it's worth working around this problem in curl. Attached is a patch that adds a --disable-tftp-options option which does exactly that. I've tested it against git mainline as well as against 0.21.0.

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2010-09-02 22:41

Message:
Thanks for your work on this and the new suggestion.

Yes, I would prefer that solution with a big comment added where the code
is explaining the reasoning for it. It is probably pretty low risk as it is
only for a single block and the 65535 block will already have been acked
when the bad ack arrives for block 0.

I prefer it primarily since it doesn't add any option so thus the
unknowing users won't need to figure out that they need to set an option
just because their server happens to be a broken implementation.

----------------------------------------------------------------------

Comment By: Tim Newsome (timnewsome)
Date: 2010-09-02 02:17

Message:
I have submitted a patch to fix the bug in tftpd-hpa to that project's
mailing list:
http://syslinux.zytor.com/archives/2010-September/015253.html
But even if it is accepted today, there will still be quite a lot of time
before it makes it into all the distributions.

It might be possible to work around the problem in another way, but I
think it would be more work.
When the block number that curl sends rolls over from 65535 to 0, tftpd
sends curl a bogus ack with a block number of 65535 and some trailing
garbage. Looking at tftpd's code. If curl just keeps going on everything
should just work. (What actually happens is that curl retransmits the 0
block because it wasn't acked.) I haven't tested this, so I might be
missing something.

So I think if curl accepts an ack-65535 where it expects ack-0, things
will also work. Do you prefer that solution?

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-02 01:05

Message:
First, my debian offers an additional tftpd server.

Why aren't you instead spending this effort on fixing the tftpd-hpa
server?

Can you provide any pointers to details about this problem you're
referring to? Isn't there any way we can probe or work around the problem
run-time? I really dislike adding options like this that the user just have
to know needs ot be set or bad things happen.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3057696&group_id=976
Received on 2010-09-02