From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] U-Boot & FTP
Date: Wed, 5 Jan 2005 08:54:50 -0500 [thread overview]
Message-ID: <41DBF1AA.1020803@smiths-aerospace.com> (raw)
In-Reply-To: <20050105004655.3CCBCC108D@atlas.denx.de>
Wolfgang Denk wrote:
> Dear Tolunay,
>
> in message <41DB36C9.3080807@orkun.us> you wrote:
>
>>I can think of one case where FTP would be desirable. If the host is
>>behind a stateful firewall and TFTP Server is on the other side, the
>
>
> I'm not sure if it is a good idea to attempt to run TFTP across a
> firewall. If you need a firewall, you don't want to have TFTP traffic
> running through it.
>
>
>>client might not be able to access the TFTP server properly. Because per
>
>
> How about using NFS?
>
>
>>but I can see it may be needed by some. A very basic lightweight and
>>tight TCP support could be developped for FTP support. There are some
>>TCP implementations for really limited resource hosts.
>
>
> I didn't say it is impossible. It's just unlikely to be added.
>
> Best regards,
>
> Wolfgang Denk
Wolfgang has higher standards than most of us ;-) and thus has not had
the "pleasure" of working with Windows. With Windows XP SP2
firewalling, TFTP loading using a Windows box as the server breaks by
default because the firewalling blocks the u-boot TFTP inbound requests.
Our customer requested, and I plan to implement Real Soon Now, that the
u-boot TFTP source port be configurable: my plan is to make an
environment variable:
* If set, use that port as the u-boot source port
* If not set, use the current method of using a pseudo random port
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 XP firewall,
allowing the remainder of the TFTP transfer to proceed normally.
This is ugly and requires a preconfigured, known system (but can be
aided by some extra knowledge like a DHCP configuration request just
occurred therefore a TFTP load is going to happen Real Soon Now) BUT it
does allow our customer to provide a system that _their_ customer
doesn't need to know how to modify firewall rules.
...and that is how the Dumbing Down of the World occurs :-(.
I will provide a patch when I get it working and I will understand 100%
if Wolfgang rejects it. Perhaps we can use the SourceForge "upload
patch" feature to store patches that a few people find useful but are
not of general use and are rejected by Wolfgang.
gvb
next prev parent reply other threads:[~2005-01-05 13:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-04 21:17 [U-Boot-Users] U-Boot & FTP D Palmer
2005-01-04 21:22 ` Jerry Van Baren
2005-01-04 22:19 ` Wolfgang Denk
2005-01-05 0:37 ` Tolunay Orkun
2005-01-05 0:46 ` Wolfgang Denk
2005-01-05 13:54 ` Jerry Van Baren [this message]
2005-01-05 14:44 ` Marius Groeger
2005-01-05 14:58 ` Jerry Van Baren
2005-01-05 15:31 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41DBF1AA.1020803@smiths-aerospace.com \
--to=gerald.vanbaren@smiths-aerospace.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox