another request-options question

[Christopher Barry]

On Thu, 2009-10-22 at 00:09 +0200, Denys Vlasenko wrote:
> On Tuesday 20 October 2009 04:58, Christopher Barry wrote:
> > This question is specific to udhcpc, hopefully this is the right place
> > to pose it.
> > 
> > I'm defining an option in ISC dhcpd to send a non-standard server IP to
> > clients. I'm planning on using -O to have the client ask for it.
> > 
> > Will this option appear as a variable in my environment as the name of
> > the option I define?
> 
> Looking at the code, no, it won't. Only those in dhcp_option_strings[]
> will.
> 
> BTW, any "-O option" is also checked against dhcp_option_strings[]
> and won't be accepted if it is not found there. You can't request
> options which udhcpc doesn't know. Understandably, because udhcpc
> needs to know their *format* - is it an IP? String? Integer?
> Pair of IPs? etc.

So, when I define the option in ISC dhcpd, and give it a type of
ip-address, this format specification data is not sent to the client?
How can any dhcp client understand new options defined on the server? Is
this limitation particular to udhcpc?

Should I be looking at using another dhcp client to solve this? Or, is
adding this option to udhcpc source fairly simple? How have others
tackled this problem?


> 
> > Assuming so, will this variable be in the environment of the script that
> > fires off udhcpc, or will it be available in a script run by an event?
> 
> I don't understand this question. There is only one script which
> is run by udhcpc, the question assumes there are two kinds of scripts.

I was assuming - yes. I made the leap that each even could run a
separate script. Are these simply handled in a single script?