cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Trouble with libcurl vs. old/incomplete TFTP servers

From: Michael König <plasm_at_plasm.de>
Date: Wed, 19 Aug 2015 17:54:56 +0200 (CEST)

Hi!

> Daniel Stenberg <daniel_at_haxx.se> hat am 19. August 2015 um 09:47 geschrieben:
>
>
> On Mon, 17 Aug 2015, Michael König wrote:
>
> > When trying to use libcurl with some embedded TFTP server implementation i
> > ran into trouble, due to faulty TFTP option handling.
>
> Thanks!
>
> I'm generally a bit cautious about adding work-around for specific server
> flaws unless they're in really wide use. Do you know anything about what
> software/version this particular server is or how commonly it is used?
We sold around 1.3 million routers/APs total until this day. I cannot say how
many of those are in use. The behaviour of the TFTP implementation was fixed
recently. Before that all devices were affected.

My change is still fully within the scope of the TFTP RFC. It just dumbs the
libcurl implementation of TFTP down to the state of RFC 1350 without the TFTP
options, when CURLOPT_TFTP_NO_OPTIONS is set.
>
> > In this case the server reported a transfer size of 0, instead of just
> > omitting the size, because it was unknown. This caused libcurl to do exactly
> >
> > nothing, which was correct, but not what i hoped for. The server behaved as
> > intended, when the TFTP options were missing from the read request. To
> > enable libcurl to do something like this i added a new option
> > "CURLOPT_TFTP_NO_OPTIONS" to curl_easy_setopt(), which when set to 1 omits
> > any TFTP options from read or write requests.
>
> Based on my understanding of your patch, this only prevents libcurl from
> sending any options. Given your explanation above, wasn't the problem that the
>
> server sent an unexpected option + value ?
The option was expected, but the associated value sent by the server signalled
that there was nothing for the client to do. So libcurl did exactly that.

Behaviour of the unpatched TFTP server is that, when confronted with a sent
tsize option in an RRQ it responds with a zero size instead of omitting the
tsize option. If no options are sent, it just starts sending data.

The code i am working on MUST work against the older firmware versions. My way
of achieving that was to give libcurl a way to play the role of a client that
just implements RFC 1350 and nothing else.
>
> --
>
> / daniel.haxx.se

Thanks,
  Michael

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-08-19