http://defect.opensolaris.org/bz/show_bug.cgi?id=8475
--- Comment #2 from James Carlson <james.d.carlson at sun.com> 2009-04-28 04:08:09 --- (In reply to comment #0) > ath0: flags=1004803<UP,BROADCAST,MULTICAST,DHCP,IPv4> mtu 1500 index 3 > inet 192.168.1.7 netmask ffffff00 broadcast 192.168.1.255 [...] > # dladm show-wifi > LINK STATUS ESSID SEC STRENGTH MODE > SPEED > ath0 disconnected -- -- -- -- -- That's symptomatic of a "feature" in dhcpagent. If the client is unable to contact the DHCP server for *any* reason, and if it has cached DHCP information, then it will use that information. The cached information can come from two places. If you don't have RELEASE_ON_SIGTERM set, then /etc/dhcp/*.dhc files will hold old leases on shutdown and allow the client to pick them back up on boot. The other possible source is suspend/resume: if you suspend your machine and then resume it in a new location, we'll still have the lease around in RAM, and will try to revalidate it. In Picea, I added code that deliberately wipes out the address (sets to 0.0.0.0 for IPv4 and unplumbs for IPv6) if the interface is not preferred. Not sure what the equivalent for Phase 1 should be. -- 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. You are the assignee for the bug.
