<div dir="ltr"><div>Hi Stefan,</div><div><br></div>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.<div><br></div><div>
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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>Andreas</div><div> <br><div><br><div class="gmail_quote"><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><span style="font-family:'Helvetica';color:rgba(0,0,0,1.0)"><b>From: </b></span><span style="font-family:'Helvetica'">Stefan Zegenhagen <<a href="mailto:stefan.zegenhagen@arcutronix.com" target="_blank">stefan.zegenhagen@arcutronix.com</a>><br>

</span></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">
<span style="font-family:'Helvetica';color:rgba(0,0,0,1.0)"><b>Subject: </b>
</span><span style="font-family:'Helvetica'"><b>Re: Fwd: FW: [erlang-bugs] Bug in TFTP client implementation?</b><br>
</span></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">
<span style="font-family:'Helvetica';color:rgba(0,0,0,1.0)"><b>Date: </b></span><span style="font-family:'Helvetica'">6 Mar 2014 17:21:10 GMT+1<br>
</span></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">
<span style="font-family:'Helvetica';color:rgba(0,0,0,1.0)"><b>To: </b></span><span style="font-family:'Helvetica'">Andreas Schumacher <<a href="mailto:andreas@erlang.org" target="_blank">andreas@erlang.org</a>><br>

</span></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">
<span style="font-family:'Helvetica';color:rgba(0,0,0,1.0)"><b>Cc: </b></span><span style="font-family:'Helvetica'"><<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>><br>

</span></div>
<br>
<div>Dear all,<br>
<br>
<br>
<blockquote type="cite">According to the initial connection protocol, which is used to establish a<br>
"pseudo" connection between the client and the server, the client sends its<br>
first datagram to the server's well-known port (69). The server sends<br>
its packet<br>
(here: ACK) from a freshly allocated ephemeral port, and all future packets<br>
to the server should be sent to this port. Consequently, if the server<br>
decides to allocate that port on a different host, then it seems sensible<br>
that the client uses the server's unique socket 3-tuple (protocol,<br>
ip-address, port) for all future packets to that server.<br>
<br>
In short, there are no plans to change the current TFTP client behaviour,<br>
unless further information is provided, which indicates that a different<br>
behaviour would be more appropriate.<br>
</blockquote>
<br>
I fully agree with your reasoning. On the other hand, I have a real<br>
problem that, unfortunately, I need to solve.<br>
<br>
<br>
I found no way to amend the sitation: neither could I tell the TFTP<br>
servers to listen for *ALL* IPv6 communication (bind to "::"), nor could<br>
I tell the Windows OS to ignore IPv6 router advertisements and automatic<br>
address configuration.<br>
Using the automatically configured IPv6 address is not an option as well<br>
because IPv6 Privacy Extensions are enabled and cannot be disabled, so<br>
that the IPv6 address changes in regular intervals.<br>
(I have to admit that I am not familiar with the Windows OS and that<br>
there may be ways to disable IPv6 autoconfiguration that escaped my<br>
attention and internet searching capabilities so far.)<br>
<br>
<br>
I could imagine a solution like this:<br>
<br>
We *KNOW* that we can contact the TFTP server under the user's selected<br>
IP address because we get a valid response to the initial request. If we<br>
try to use the user-supplied IP address for the next packet we send and<br>
get a timeout, we can still assume that further communication was<br>
reallocated to a different host and use the IP address that we got the<br>
reply from. Or vice versa.<br>
<br>
In order to keep the current level of security, I would still record the<br>
remote hosts source address and check that further packets are received<br>
from the same source address, even if we send packets only to the<br>
user-supplied IP address.<br>
<br>
<br>
<br>
Kind regards,<br>
<br>
-- <br>
Dr. Stefan Zegenhagen<br>
<br>
arcutronix GmbH<br>
Garbsener Landstr. 10<br>
30419 Hannover<br>
Germany<br>
<br>
Tel:   <a href="tel:%2B49%20511%20277-2734" value="+495112772734" target="_blank">+49 511 277-2734</a><br>
Fax:   <a href="tel:%2B49%20511%20277-2709" value="+495112772709" target="_blank">+49 511 277-2709</a><br>
Email: <a href="mailto:stefan.zegenhagen@arcutronix.com" target="_blank">stefan.zegenhagen@arcutronix.com</a><br>
Web:   <a href="http://www.arcutronix.com" target="_blank">www.arcutronix.com</a><br>
<br>
*Synchronize the Ethernet*<br>
<br>
General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer -<br>
Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht<br>
Hannover; Ust-Id: DE257551767.<br>
<br>
Please consider the environment before printing this message.<br>
<br>
</div>
</blockquote>
</div>
<br>
</div>

</div><br></div></div></div>