Multiple problems in DHCP client

[Chris Johns]

On 6/05/11 11:02 PM, Sebastien Bourdeauducq wrote:
>
> I have several concerns reading the DHCP client code:
> 1) When the /etc/resolv.conf file is built, the code reads the
> rtems_bsdnet_ntpserver table instead of the rtems_bsdnet_nameserver
> table (line 1092 of rtems_dhcp.c). Was this code tested?

This is a bug. Yes it has been tested and so I am not sure what effect 
the bug has. It has been there forever. I suspect the entries may be the 
same when tested and therefore no problems where noticed or a valid 
resolv.conf masked over any issue.

> 2) Why do we need to build an /etc/resolv.conf at all, since the
> resolver already reads the rtems_bsdnet_nameserver table directly in
> res_init()?

Because the resolver reading these tables is an addition to RTEMS. A new 
stack will break any code that depends on these tables. I will resist 
these tables appearing in a new stack.

The stack was added before we had a stable file system that all targets 
can use. There are a range of files the stack needs to work well in a 
number of system configurations. I would prefer the files be the main focus.

> 3) The variable rtems_bsdnet_nameserver_count is not set to 0 at the
> beginning of the DHCP request, which means that when DHCP is restarted,
> the DNS entries keep piling up until the table is full (3 entries), at
> which point the new DNS will not be taken into account at all.

Another bug. The difficultly is a user who mixes the DHCP supplied 
entries and initialised entries in the rtems_bsdnet_nameserver table. If 
just the file was created would this solve the issue ?

> 4) For the new name servers to be taken into account, it seems that
> res_init() has to be called. This function is run on the first call to
> another name resolver function, and sets up the resolver internal state
> according to the rtems_bsdnet_nameserver table and /etc/resolv.conf (if
> any). I think it should be called again to take into account
> modifications to the DNS settings, but it is not clear to me how and
> when it should be done, especially wrt locking (what happens if
> res_init() is preempted in the middle of a modification of the resolver
> state by another task that happens to do a DNS resolution?).

I thought the stack would keep an eye on resolv.conf. I know on a 
FreeBSD system I can just edit any time and the change take effect.

Chris