fresh webrev in place, I've retested and it seems to resolve all the issues described in 11437, 11092 and 10707. We're seeing some weirdness with DHCPv6 and autoconf that John has kindly spent some time investigating, this likely results from us having to rely on regular router advertisements rather than sending solicitations when IPv6 is plumbed. The same behaviour is observed outside of NWAM so it doesn't seem to be an NWAM-specific issue.
One other weird thing we see on John's test machine - DHCPv4 takes a long time to respond sometimes (>60sec), despite nwamd doing the right thing in starting DHCP during the configuration phase. Webrev is at: http://zhadum.east/export/ws/amaguire/nwam1-fixes/webrev/ Alan Alan Maguire wrote: > Renee Danson Sommerfeld wrote: >> Hi Alan, >> >> On Fri, Sep 18, 2009 at 09:22:24PM +0100, Alan Maguire wrote: >> >>> see webrev at: >>> >>> http://zhadum.east/export/ws/amaguire/nwam1-fixes/webrev/ >>> >> >> Looks good, just one question: in ncu_ip.c'start_dhcp_thread(): >> at line 1390, you changed a sockaddr_in to a sockaddr_storage; >> I'm not sure why? We are only dealing with v4 addrs in here. >> >> > when synthesizing the IF_STATE event, I was > seeing coredumps when it was just a sockaddr_in - > I'm assuming libumem is sensitive to the fact we're > bcopy'ing past the end of the sockaddr_in (not sure, > but fixing it to be a sockaddr_storage, which > nwamd_event_init_if_state() worked). >> If there is a reason for using a sockaddr_storage, then it seems >> odd to keep alen = sizeof (struct sockaddr_in) (line 1391). >> >> > Yep, for v4 addr we only need v4 addrlen, but > for synthesizing the IF_STATE event we > need the full sockaddr_storage size. > > Alan > _______________________________________________ > nwam-dev mailing list > nwam-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-dev
