[erlang-bugs] Fwd: FW: Bug in TFTP client implementation?

[Andreas Schumacher]

Unfortunately, RFC 1350 - The TFTP Protocol (Revision 2) - does not address
this issue. Nevertheless, based on TFTP's initial connection protocol and
its relation to the underlying protocols, the Erlang/OTP TFTP client
behaviour seems to be sensible in this case.

According to the initial connection protocol, which is used to establish a
"pseudo" connection between the client and the server, the client sends its
first datagram to the server's well-known port (69). The server sends
its packet
(here: ACK) from a freshly allocated ephemeral port, and all future packets
to the server should be sent to this port. Consequently, if the server
decides to allocate that port on a different host, then it seems sensible
that the client uses the server's unique socket 3-tuple (protocol,
ip-address, port) for all future packets to that server.

In short, there are no plans to change the current TFTP client behaviour,
unless further information is provided, which indicates that a different
behaviour would be more appropriate.

Andreas Schumacher, Erlang/OTP, Ericsson AB


-----Original Message-----
From: erlang-bugs-bounces@REDACTED [mailto:erlang-bugs-bounces@REDACTED]
On Behalf Of Stefan Zegenhagen
Sent: den 5 mars 2014 16:53
To: erlang-bugs@REDACTED
Subject: [erlang-bugs] Bug in TFTP client implementation?

Dear all,

There might be a bug in erlang's TFTP client implementation that prevents
erlang to successfully transfer files over IPv6 with many
Microsoft(R) Windows TFTP servers.

Those TFTP servers (most of them are available free of charge) are capable
to bind to a single IP address only, not to an interface. The problem
arises when the server has statically configured IPv6 addresses as well as
automatically configured ones. Here's the step-by-step error
description:

     1. start the Windows TFTP server and bind to the static IPv6 server
        address
     2. call tftp:read_file(...) to download a file from the TFTP server
        using the static IPv6 server address
     3. transmission of packets is as follows:

<client IPv6> => <static server IPv6> : Write Request <dynamic server IPv6>
=> <client IPv6> : Ack, Port #xxxx

<client IPv6> => <dynamic IPv6>:xxxx : Data block=0

It appears that the TFTP servers are unwilling (or unable) to respond from
the IPv6 address they have been contacted at.

Furthermore it seems that the erlang TFTP client uses the source IPv6 of
the received Ack packet in all further communication. Since the TFTP server
is not listening to its dynamic IPv6 address (from which it always
responds, though), the data blocks transmitted after the initial successful
"connection establishment" are never received by the TFTP server.

I agree that the TFTP server should respond from the IPv6 address it was
contacted at. However, I also think it to be a questionable behaviour to
change to a different IP address for the actual data transfer.



Kind regards,

--
Dr. Stefan Zegenhagen

arcutronix GmbH
Garbsener Landstr. 10
30419 Hannover
Germany

Tel:   +49 511 277-2734
Fax:   +49 511 277-2709
Email: stefan.zegenhagen@REDACTED
Web:   www.arcutronix.com

*Synchronize the Ethernet*

General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal
Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover;
Ust-Id: DE257551767.

Please consider the environment before printing this message.

_______________________________________________
erlang-bugs mailing list
erlang-bugs@REDACTED
http://erlang.org/mailman/listinfo/erlang-bugs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20140306/536a0d92/attachment.htm>