[U-Boot] [RFC] Preventing overriding of serverip when set in environment by user

[Wolfgang Denk]

Dear Chase,

In message <7D46E86EC0A8354091174257B2FED10138DD6FB8 at 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Let the programmers be many and the managers few -- then all will  be
productive.               -- Geoffrey James, "The Tao of Programming"