[U-Boot-Users] PATCH: Force TFTP to use a fixed UDP port

[U-Boot-Users] PATCH: Force TFTP to use a fixed UDP port

[Jerry Van Baren]

Hi Wolfgang,

Attached is a patch to allow the user to set an environment variable 
"tftpourport" to force TFTP to use that value for "TftpOurPort" (our UDP 
port).  As discussed yesterday on this list, this is helpful for 
"punching through" a firewall such as is installed with Windows XP SP2.

Making it an environment variable is cute but an overkill.  If there is 
an outcry over the level of overkill, I would be willing to make the 
UDP port a simple #define of a compile time constant, in which case it 
would actually save a few bytes of ROM over the pseudo-random algorithm :-).

Thanks,
gvb


CHANGELOG:

* Patch by Jerry Van Baren 05 Jan 2005
  - Make the u-boot TFTP source port be configurable using the
    environment variable "tftpourport":
    * If set, use that port as the u-boot source port
    * If not set, use the current method of using a pseudo random port

  - The additional code can be totally removed by setting the
    #define TFTP_PORT_FROM_ENV (in the net/tftp.c file) to zero.

  - The purpose behind this change is that our customer will
    modify their TFTP server so that it blindly starts the
    TFTP transfer using the pre-configured target IP address
    and UDP port. This will have the effect of "punching through"
    the (Windows XP) firewall, allowing the remainder of the TFTP
    transfer to proceed normally.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 050105.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20050106/44ee598e/attachment.txt 

[U-Boot-Users] PATCH: Force TFTP to use a fixed UDP port

[Wolfgang Denk]

In message <41DDB3DE.4010403@smiths-aerospace.com> you wrote:
>
> Attached is a patch to allow the user to set an environment variable 

Please change a few things:

> "tftpourport" to force TFTP to use that value for "TftpOurPort" (our UDP 

Please use a more straightforward name, like "tftpport" or
"tftp-port" or so.

Please document the variable in the README.

>   - The additional code can be totally removed by setting the
>     #define TFTP_PORT_FROM_ENV (in the net/tftp.c file) to zero.

This is unacceptable.  First,  please  make  this  a  CONFIG_*  name.
Second,  please  make  it  such that you have to explicitely _enable_
this option when you want it,  instead  of  making  it  the  default.
Finally, please use #ifdef instead of #if.

>   - The purpose behind this change is that our customer will
>     modify their TFTP server so that it blindly starts the
>     TFTP transfer using the pre-configured target IP address
>     and UDP port. This will have the effect of "punching through"
>     the (Windows XP) firewall, allowing the remainder of the TFTP
>     transfer to proceed normally.

Such verbosity is inacceptable for the  CHANGELOG.  Move  it  to  the
README or a doc/ file.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The human mind ordinarily operates at only ten percent of its capaci-
ty - the rest is overhead for the operating system.

[U-Boot-Users] PATCH: Force TFTP to use a fixed UDP port

[Tolunay Orkun]

I think you are doing something wrong with your Windows box. I have just 
tried 2 tftp servers (one running as service and another running as 
application) on Windows XP box and no such trickery that you prosed was 
needed.

You just have to tell Windows Firewall to unblock the application (or 
the executable for the service) and it works perfectly. What exactly is 
your configuration?

The only TFTP firewall issue I know is when client is behind a stateful 
firewall or NAT device, in which case the dynamic port chosen by the 
server for conducting the transfer (beyond 1st packet) gets blocked by 
the firewall. Source port of TFTP client is not an issue in that case. 
When server is behind a stateful firewall, this is not an issue!

I am having hard time understanding your issues. Can you describe the XP 
firewall issues a bit more in detail? I am feeling this patch is not 
really needed.

Best regards,
Tolunay

Jerry Van Baren wrote:
> Hi Wolfgang,
> 
> Attached is a patch to allow the user to set an environment variable 
> "tftpourport" to force TFTP to use that value for "TftpOurPort" (our UDP 
> port).  As discussed yesterday on this list, this is helpful for 
> "punching through" a firewall such as is installed with Windows XP SP2.
> 
> Making it an environment variable is cute but an overkill.  If there is 
> an outcry over the level of overkill, I would be willing to make the UDP 
> port a simple #define of a compile time constant, in which case it would 
> actually save a few bytes of ROM over the pseudo-random algorithm :-).
> 
> Thanks,
> gvb
> 
> 
> CHANGELOG:
> 
> * Patch by Jerry Van Baren 05 Jan 2005
>  - Make the u-boot TFTP source port be configurable using the
>    environment variable "tftpourport":
>    * If set, use that port as the u-boot source port
>    * If not set, use the current method of using a pseudo random port
> 
>  - The additional code can be totally removed by setting the
>    #define TFTP_PORT_FROM_ENV (in the net/tftp.c file) to zero.
> 
>  - The purpose behind this change is that our customer will
>    modify their TFTP server so that it blindly starts the
>    TFTP transfer using the pre-configured target IP address
>    and UDP port. This will have the effect of "punching through"
>    the (Windows XP) firewall, allowing the remainder of the TFTP
>    transfer to proceed normally.
> 
> 
> ------------------------------------------------------------------------
> 
> Index: net/tftp.c
> ===================================================================
> RCS file: /cvsroot/u-boot/u-boot/net/tftp.c,v
> retrieving revision 1.9
> diff -p -u -r1.9 tftp.c
> --- net/tftp.c	15 Apr 2004 21:48:55 -0000	1.9
> +++ net/tftp.c	6 Jan 2005 03:20:41 -0000
> @@ -24,6 +24,9 @@
>  					/* (for checking the image size)	*/
>  #define HASHES_PER_LINE	65		/* Number of "loading" hashes per line	*/
>  
> +#define TFTP_PORT_FROM_ENV	1	/* define this to allow setting the	*/
> +					/* TFTP source port in the environment	*/
> +					/* variable "tftpourport"		*/
>  /*
>   *	TFTP operations.
>   */
> @@ -301,6 +304,8 @@ TftpTimeout (void)
>  void
>  TftpStart (void)
>  {
> +	char *ep;             /* Environment pointer */
> +
>  	if (BootFile[0] == '\0') {
>  		IPaddr_t OurIP = ntohl(NetOurIP);
>  
> @@ -354,7 +359,13 @@ TftpStart (void)
>  	TftpServerPort = WELL_KNOWN_PORT;
>  	TftpTimeoutCount = 0;
>  	TftpState = STATE_RRQ;
> +	/* Use a pseudo-random port unless a specific port is set */
>  	TftpOurPort = 1024 + (get_timer(0) % 3072);
> +#if TFTP_PORT_FROM_ENV
> +	if ((ep = getenv("tftpourport")) != NULL) {
> +		TftpOurPort= simple_strtol(ep, NULL, 10);
> +	}
> +#endif
>  	TftpBlock = 0;
>  
>  	/* zero out server ether in case the server ip has changed */

[U-Boot-Users] PATCH: Force TFTP to use a fixed UDP port

[Jerry Van Baren]

Tolunay Orkun wrote:
> I think you are doing something wrong with your Windows box. I have just 
> tried 2 tftp servers (one running as service and another running as 
> application) on Windows XP box and no such trickery that you prosed was 
> needed.
> 
> You just have to tell Windows Firewall to unblock the application (or 
> the executable for the service) and it works perfectly. What exactly is 
> your configuration?

You understand it perfectly and it works perfectly as you describe.  The 
problem isn't Windows XP firewall per se, it is stupid customers.  They 
either don't understand the firewall (quite likely) and/or their machine 
is "locked down" by their IT staff so that they cannot unblock TFTP (a 
very serious problem).  They expect to plug in our customer's software 
and have it "just work."  When it doesn't, it is a major support 
headache for our customer and hurts their reputation.

> The only TFTP firewall issue I know is when client is behind a stateful 
> firewall or NAT device, in which case the dynamic port chosen by the 
> server for conducting the transfer (beyond 1st packet) gets blocked by 
> the firewall. Source port of TFTP client is not an issue in that case. 
> When server is behind a stateful firewall, this is not an issue!

...and this patch won't help in that case.

> I am having hard time understanding your issues. Can you describe the XP 
> firewall issues a bit more in detail? I am feeling this patch is not 
> really needed.

Agreed, it isn't a necessary patch, but it is one that would help our 
customer (who has to deal with stupid customers).  I'll clean up the 
patch per Wolfgang's email and resubmit it.  If it is accepted, maybe it 
will help someone else with stupid customers.  If not, it will remain in 
_our_ build and will help _our_ customer with his stupid customers.

gvb
P.S. The customer is always right (even if he is stupid ;-)

> Best regards,
> Tolunay
> 
> Jerry Van Baren wrote:
> 
>> Hi Wolfgang,
>>
>> Attached is a patch to allow the user to set an environment variable 
>> "tftpourport" to force TFTP to use that value for "TftpOurPort" (our 
>> UDP port).  As discussed yesterday on this list, this is helpful for 
>> "punching through" a firewall such as is installed with Windows XP SP2.
>>
>> Making it an environment variable is cute but an overkill.  If there 
>> is an outcry over the level of overkill, I would be willing to make 
>> the UDP port a simple #define of a compile time constant, in which 
>> case it would actually save a few bytes of ROM over the pseudo-random 
>> algorithm :-).
>>
>> Thanks,
>> gvb