I forgot to cc the networking-discuss mailing list
and include the changes for suspend/resume use in
the previous write up. Here is the updated DHCP
changes. Please take a look. Thanks.
--
K. Poon.
[EMAIL PROTECTED]
DHCP related changes for NWAM
Background
----------
When NWAM detects that an IP interface is available (the
IFF_RUNNING flag is set), it needs to decide how to configure
the interface by consulting a "profile." A "profile" may
specify that this interface is to have a static IP address.
Or it may specify that this interface is to be configured using
DHCP. Or it may specify that depending on different "conditions,"
this interface is to be configured using different methods. Or
it may not specified any method to configure the new interface,
and NWAM needs to decide what to do with it.
In the last two cases above, NWAM needs to discover what is
available using the new interface. For example, it needs to
find out if a DHCP server is available through the new interface.
Currently, Solaris' dhcpagent(1M) does not provide a detection
method which a caller can request the dhcpagent to find out the
DHCP information on a given interface. When DHCP is enabled on an
interface, the dhcpagent will try to complete the full DHCP
lease processing and bind the interface. This document is to
introduce a discover method to the dhcpagent without doing
the actual lease processing.
Proposal
--------
1. dhcpagent changes
In order to satisfy the above need to NWAM, we propose to add a new
discover mechanism to dhcpagent. A new DHCP_DISCOVER request is
added. When the dhcpagent receives such a discover request, it
will send out the DHCPDISCOVER message through the requested interface
as if it is trying to obtain a lease of an IP address from a server.
A caller can also spsecify an address in the request. If there is
an address, dhcpagent will include the Requested IP Address (code 50)
option with that address in the DHCPDISCOVER message. After the
dhcpagent receives the DHCPOFFER message from a server, it will reply
the discover request with an OK. The agent will remember this
DHCPOFFER message for a specific period of time. If dhcpagent receives
multiple offers, it will remember all of them. And each offer is
assigned a non-zero index. During this period, the internal state of
the interface is DISCOVERED. After this period, the state will be
changed back to INIT and all the cached DHCPOFFER messages will be
freed.
If the dhcpagent receives the discover request on an interface
which is already in BOUND state, it will reply the request with an
error DHCP_IPC_E_OUTSTATE. As the discover request is asynchronous,
the agent may reply with error DHCP_IPC_E_PEND. It is up to the caller
to retry.
After the discover request is finished, the requester can then retrieve
information from the DHCPOFFER message(s) using the DHCP_GET_ALL_TAG
request. This new request can return data either from DHCPOFFER or
DHCPACK. The caller can specify which one it wants in the request.
If a caller requests data from DHCPOFFER, dhcpagent will return
all the received DHCPOFFER messages along with their assigned index
to the caller. If a caller requests data from DHCPACK, dhcpagent
will return the received DHCPACK message to the caller.
The DHCP_START request is also modified. The caller can specify
an index in the request to tell the dhcpagent which DHCPOFFER
message to use in generating the DHCPREQUEST message to the DHCP
server. If the index is 0, it means that the dhcpagent can
use the current rules to pick the appropriate DHCPOFFER message.
If a DHCP_START request comes in for an interface in DISCOVERED
state, the dhcpagent will generate a DHCPREQUEST message based
on the saved DHCPOFFER message(s). Which message to use is
determined by the aforementioned index in the request. If the index
is non-zero and the interface is not in DISCOVERED state, the error
DHCP_IPC_E_OUTSTATE will be sent back to the caller. After the
DHCP lease is acquired, dhcpagent will still cache all the received
DHCPOFFER messages for diagnostic purpose. Their information can
be retrieved using the DHCP_GET_ALL_TAG request.
2. dhcpinfo(1) changes
Two new options, -o and -a , will be added to dhcpinfo. If the
-o option is set, dhcpinfo will request information from the
DHCPOFFER message and print out the result. If not set, it will
request information from the DHCPACK message as is done currently.
The -o option takes a parameter which is used to specify which
DHCPOFFER message to retrieve the result from. If there is no
option, it will return results from all the DHCPOFFER messages
stored in dhcpagent.
If the -a option is set, dhcpinfo will print out all fields from
either DHCPOFFER or DHCPACK message, depending on whether the -o
option is set.
3. ifconfig(1M) changes
Two new dhcp sub-commands `discover' and `select <x>' are added to
ifconfig. The `discover' sub-command asks ifconfig to send the
DHCP_DISCOVER request to the dhcpagent. The `select <x>' sub-
command asks ifconfig to send the DHCP_START request with an index
<x> to the dhcpagent. The current `start' sub-command will send
a DHCP_START request with 0 as the index.
_______________________________________________
networking-discuss mailing list
[email protected]
