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

[Andreas Schumacher]

Hi Stefan,

I have spent some further thoughts on the issue, and have come to a
different conclusion; although, it may change again if I continue to think
about it.

After browsing some pages on TFTP and load balancing, NAT, VIP, etc., the
following TFTP client behaviour seems to be most appropriate: If the
response is not coming from the IP address to which the client sent the
request, the client should ignore the response.

The second best response may be that the client continues to use the
original server IP address. However, the implementation of that behaviour
would be considered a low priority change request; and thus, it may only be
implemented in the foreseeable future if you or someone else provides a
patch.

The solution that you proposed adds too much unnecessary complexity to a
supposedly simple protocol; and thus, it is not considered to be a suitable
solution alternative.

Nevertheless, since you seem to have problems with different Windows TFTP
servers, I wonder whether your Windows IP configuration and/or server
configuration are correct. Unfortunately, I am not able to help you with
that part.

Andreas


*From: *Stefan Zegenhagen <stefan.zegenhagen@REDACTED>
 *Subject: * *Re: Fwd: FW: [erlang-bugs] Bug in TFTP client implementation?*
 *Date: *6 Mar 2014 17:21:10 GMT+1
 *To: *Andreas Schumacher <andreas@REDACTED>
 *Cc: *<erlang-questions@REDACTED>

Dear all,


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.


I fully agree with your reasoning. On the other hand, I have a real
problem that, unfortunately, I need to solve.


I found no way to amend the sitation: neither could I tell the TFTP
servers to listen for *ALL* IPv6 communication (bind to "::"), nor could
I tell the Windows OS to ignore IPv6 router advertisements and automatic
address configuration.
Using the automatically configured IPv6 address is not an option as well
because IPv6 Privacy Extensions are enabled and cannot be disabled, so
that the IPv6 address changes in regular intervals.
(I have to admit that I am not familiar with the Windows OS and that
there may be ways to disable IPv6 autoconfiguration that escaped my
attention and internet searching capabilities so far.)


I could imagine a solution like this:

We *KNOW* that we can contact the TFTP server under the user's selected
IP address because we get a valid response to the initial request. If we
try to use the user-supplied IP address for the next packet we send and
get a timeout, we can still assume that further communication was
reallocated to a different host and use the IP address that we got the
reply from. Or vice versa.

In order to keep the current level of security, I would still record the
remote hosts source address and check that further packets are received
from the same source address, even if we send packets only to the
user-supplied IP address.



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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20140306/138ce4dc/attachment.htm>