Dear Chase,

In message 7D46E86EC0A8354091174257B2FED10138DD6FB8@DLEE12.ent.ti.com you wrote:

Sorry, I didn't mean I was talking about the code on the router. I meant I was using the router as my DHCP server for my Linux host and my development board.

Cab you please restrict your line length to some 70 characters or so? Thanks.

Well, when it's your box, then why don't you configure the DHCP server correctly?

First, thanks for your response. What I am trying to fix is that I have a development board that is connected to my Linux host using a Linksys WRT54G2 router. That particular router is returning a setting in DHCP that points to the Linksys router itself as the server. In this case I want my serverip to point to my Linux host which is running a TFTP server.

As mentioned, all you have to do is to configure your DHCP server correctly. It is perfectly normal to use different servers for DHCP and TFTP. All you have to do is to configure the "next-server" parameter in DHCP to point to the TFTP server

Other routers such as a Trendnet WRLS-N300 do not exhibit this problem so this seems to be an issue with the DHCP response on the Linksys router. ...

This is a configuration option for the DHCP server.

        ... However, thinking about this my reasoning was that if

a user were to take the time to set a value for serverip in their u-boot environment then the network router should not override that

Who says it was the user who set this variable? It could as well be the result from a previous call to DHCP which returned different results (for example, because there is a pool of DHCP servers).

setting. I think of this as who should be the authority in the system. If the user has specified a setting shouldn't that have more authority than the default setup of the DHCP server, since the user should be more knowledgeable about their particular configuration?

There is a pretty clear definition here: trhe documentation says that the DHCP command may set a certain number of (documented!) environment variables. If you think you want to ignore any of these settings, then just make sure to set these to the values you like after running the DHCP command, thus ignoring the DHCP settings.

This can be done with 2 lines of trivial scripting and does not require any code changes (see my previous message).

As for fixing the DHCP server configuration I see two cases where this can be an issue:

1. In the case of this Linksys router I found no option allowing me

to change the DHCP server configuration other than to change what range of addresses it provides. So this would lead to needing to

Are you absolutely sure that the Linksys router does not support the "next-server" parameter in it's configuration?

modify the router firmware. 2. What about an environment with a shared DHCP server, where often times you may want the default value of the DHCP server for 95% of your use cases, but a particular user may want to override this setting.

Then just ognore the resuylts returnd by the DHCP server. It is all at your hands. Nobody forces you to use the address returned by the DHCP call for your TFTP downloads.

The goal of this patch was to enable user's to override the DHCP server setting by taking a pro-active action of defining serverip. In

But this is wrong, as you cannot know how the nvironment variable got set, and if it actually contains a usable value. DHCP is _supposed_ to overwrite this variable with a valid setting. Ofcourse, it is up to you if you use these results, or if you ignore them.

server could provide a value if it was configured this way. Again, it is all back to who should have ultimate authority in the system. But,

It is the user who has this authority. Which is exactly why I will not accept this patch - it would implement some policy which you think fits for your purposes - but it does not fit in general.

I can also understand your position in that if I asked the DHCP server for information I should honor the information it gives me, and if the DHCP server is giving bad information then fix the server (which may not always be possible/practical). It would always be possible to work around this by turning autoload off and then changing the bootcmd to do:

dhcp; setenv serverip xxx.xxx.xxx.xxx; tftp

Would that be our recommendation?

Yes, indeed. If you want to ignore the server reply, then please do this explicitly.

Best regards,

Wolfgang Denk