Multiple problems in DHCP client
chrisj at rtems.org
Fri May 6 21:42:54 UTC 2011
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
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.
More information about the users