http://defect.opensolaris.org/bz/show_bug.cgi?id=10406


amaguire <alan.maguire at sun.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alan.maguire at sun.com
             Status|NEW                         |CAUSEKNOWN




--- Comment #1 from amaguire <alan.maguire at sun.com>  2009-08-01 03:15:01 ---
(In reply to comment #0)
> Created an attachment (id=2357)
 --> (http://defect.opensolaris.org/bz/attachment.cgi?id=2357) [details]
> nwamd debug log, with comments
> 
> On SIGHUP, nwamd state is refreshed, and any configuration changes that
> have been made need to be applied.  However, it seems that nwamd doesn't
> check for an existing dhcp lease when doing this evaluation, so dhcp is
> restarted, and the aux state is moved from "online" to "waiting for an
> address".  However, since the lease already exists and the address is
> already assigned, dhcpagent doesn't do anything else, and nwamd never
> gets a newaddr event, leaving the interface ncu in an incorrect state.
> 
> Debug log is attached.

I think the right answer here is to modify the ncu state machine for
NWAM_AUX_STATE_INITIALIZED. At present we re-init on a SIGHUP in order to
apply/remove any addresses that are added or removed, but as part of the init
phase, we move to WAITING_FOR_ADDR. If an interface is DHCP-only, we'll get
stuck there if the address has already been applied. We could nuke things and
unplumb, allowing DHCP config to start from scratch, but that would be crazy
since it'd mean every time we got a refresh we'd rip out IP. A better approach
would be to modify nwamd_start_dhcp() (which is called if DHCP is requested on
the interface) to do an initial check for DHCPRUNNING + non-zero address. If
these conditions are satisfied, move the object online. It might make sense to
get nwamd_start_dhcp() to return a boolean value indicating if it needed to
start DHCP (if it didn't, it's already configured). If it returns false, we
know to go straight online.

-- 
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Reply via email to