[En-Nut-Discussion] Change the IP/gateway

[Pavel Chromy]

Ole Reinhardt wrote:

>> confnet.cdn_ip_addr = 192.168.1.2;
>> confnet.cdn_ip_mask = 255.255.255.0;
>> confnet.cdn_gateway = 192.168.1.2;

I think that confnet.cdn_cip should be used instead of confnet.cdn_ip.

> AFAIK you need to use the NutNetIfConfig to set these values. Before
> doing this you better should clear the values in the confnet struct.

I would not do that. I'm not sure whether calling NutNetIfConfig() second time
will work at all.

> Escpecialy it seemed to me that the dhcp config does not work properly
> if these fields are not cleared before.

Hell yes.
Though I'm great fan of Nut/OS, I must say that I really dislike this dirty way
CONFNET structure is handled in current Nut/OS - really nasty!

To not just criticise, here is my standpoint (or proposal):

1) There should be more generic way to load/save configuration from/to non-volatile memory
(why should this be the internal EEPROM memory and nothing else?).
That is, the network configuration functions should not call NutNetLoadConfig() to load single
and the only one network configuration from EEPROM - they should not do this at all,
but should rather purely rely on given parameters and leave configuration loading/saving
completely on user aplication.

Note: I experienced problems with this before - imagine an application having jumper selected
service mode forcing the device to go with DHCP or predefined configuration.
Easy to do, isn't it? Not really... what if you don't want to loose your previous network config
at once by using service mode for a while? As Nut/OS saves the configuration without asking, you need to 
either modify Nut/OS sources or have an ugly hack in you app for this :-(

2) NutNetLoadConfig() should be able to load more than one configuration (and is partly prepared for that as I have seen).
Even better, it should call a lower level function (available to application programmer), which loads
configuration from given EEPROM location (or even a file). That would be much more flexible

3) NutDhcpIfConfig() should not speculate whether to do the thing it is called for
- that is perform the DHCP request to obtaing IP configuration without hesitating.
It is logical: just read its identifier, what do you think it does or should do?
Well it does not always so...

4) There used to be a function called NutNetAutoConfig() (no marked as deprecated, why?).
I think this is the only one dedicated to "automated" stuff, this may be the only one
loading the configuration automatically, then decide whether to do DHCP or go with fixed IP and perform it.
It was previously done (almost) so.

I'll be glad to get any comments.

Pavel