http://defect.opensolaris.org/bz/show_bug.cgi?id=10406
Renee Danson Sommerfeld <renee.danson at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CAUSEKNOWN |FIXINPROGRESS
--- Comment #2 from Renee Danson Sommerfeld <renee.danson at sun.com>
2009-08-04 08:24:35 ---
(In reply to comment #1)
>
> 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.
The problem is, that all happens too late. nwamd_start_dhcp() actually does
recognize that dhcp is already running, and checks for an address. But because
the refresh triggered a whole series of events and checks, the priority group
checking happens before the event indicating the address is there, which is
scheduled by nwamd_start_dhcp(), has been handled. Before the event that
causes nwamd_start_dhcp() to be called, in fact.
The approach I've taken, as suggested by Anurag, is to reset the priority group
checking at the time of the refresh. Previously, the checking would begin with
the assumption that the wired link was up and running (active group set to 0);
since it wasn't (the appropriate events indicating that it was hadn't yet been
processed), nwamd moved on to try the next group. By resetting the active
group back to the "initialized" state (setting it to -1, the invalid group,
nwamd
actually tries to bring up the first group before starting on the second, and
then
has time to discover that the first group already is up.
The one catch is that the check after a wireless scan that prevents a
connection
from being attempted if the scanned link shouldn't be brought up needs to check
for the refresh case, where the active priority group has been reset. If this
isn't
done, the scan caused by the refresh will cause the wireless link to start
connecting,
leaving it in a weird state when the wired link becomes active.
--
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.
