Wolfgang Denk wrote:

In message E89EC5FBB92CAB4C9BB301E636B0D858075C14@mailserver4.mail4.local you wrote:

...

Are there any patches/modifications that enable U-boot to boot a kernel via FTP. ?

No, and there will be none.

FTP requires TCP/IP, which is too much overhead just for a boot loader. If you need FTP, then boot an OS which runs the download.

On the othe rhand, U-Boot offers TFTP and NFS for download, so I wonder why you think that FTP would make your life easier.

Best regards,

Wolfgang Denk

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 client might not be able to access the TFTP server properly. Because per TFTP RFC the server uses a dynamic port as source port for response packets which is detected as unsolicited by stateful firewalls and dropped. Unlike FTP this dynamic port number is not negotiated so stateful firewall cannot implement an ALG (unless ignoring the source port numbers completely which reduces the effectiveness of the firewall and is not desirable).

Such a problem did surface while updating firmware of a VOIP phone using TFTP (not u-boot related but could have been).

Now, typically the TFTP server and the U-Boot host is not seperated by a firewall but it could be in some situations. I personally do not need it 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.

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

Marius Groeger wrote:

On Wed, 5 Jan 2005, Jerry Van Baren wrote:

...

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.

...

...

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.

Which is why the OP wanted to have support _FTP_, and not TFTP.

And I still fail to see why a suitable patch for this, complying to all patch submission rules (most notably the one about not increasing the footprint when the feature is turned off), would be rejected. Granted, it's probably a lot of work, but if the guy is willing to do it...

Regards, Marius

I didn't say it would be rejected. Wolfgang said there would never be such a patch: I don't know if he meant it would be rejected or if he was predicting the future based on what has happened in the past (I suspect the latter).

The beauty of Open Source is that the OP is free to make a FTP patch. If he goes forward, bully for him. If Wolfgang subsequently rejects his patch, NBD, it met the OP's need. Furthermore, if it meets more peoples' needs, they are free to add it to their builds with or without Wolfgang's endorsement.

At this point there really isn't much point discussing hypothetical patches by OPs and hypothetical rejections by Wolfgang.

gvb