Hi Dave!
----- Original Message -----
>
> On 03/04/2013 01:06 AM, Nathan Scott wrote:
> >
> > OK, I'm at 100% pass rate for NSS-enabled-builds, and I have two
> > failures in the "native" sockets implementation, which are probably
> > the ones you've already seen & mentioned. 273 and 430, both look
> > related to pmlogger (or pmlogger PDUs) and IPv6.
> >
> > From looking into 273, it looks like in native mode, we end up in
> > a getaddrinfo() loop passing over several IPv6 addresses, etc
> > before
> > we find the IPv4 address where the connection succeeds. Strangely,
> > I thought, that this passes with NSS but not without. Looking into
> > the code, it seems the NSS implementation of __pmGetAddrInfo doesnt
> > actually call PR_GetAddrInfoByName, rather it uses
> > PR_GetHostByName?
> > Whereas the native variant does use getaddrinfo ... could this be
> > why it passes on NSS-enabled builds? Seems a bit odd.
> >
> > This is the part of 273 that is failing - there are an unexpectedly
> > high number of calls (and diagnostics) from __pmSetSocketIPC(), as
> > a
> > result of the additional calls to __pmInitSocket, as a result of
> > iterating over several possible addresses (3 x IPv6?) I guess:
> This all looks normal to me. There is no specified order in which the
> addresses may be presented in the address chain, however, I have
> observed that the NSPR implementation does tend to present the IPv4
> addresses first where the native implementation tends to present IPv6
> addresses first. That is why there are extra calls to
> __pmSetSocketIPC()
> for the native implementation when attempting to connect to pmlogger.
> The test harness needs to be updated in order to expect an
> unspecified
> number of calls to __pmSetSocketIPC(), since we have no way of easily
> knowing how the local network is configured.
*nod*, will look into that today.
Is sorting the addresses something we should be doing (in the libpcp
native implementation)? Since NSPR has decided to, I guess there was
a very good reason, and having different behaviours between different
builds of PCP seems potentially problematic.
> Having said that, gethostbyname() (via PR_GetHostByName()) is
> deprecated
> in favour of getaddrinfo(), so the NSPR implementation should be
> changed
> to call PR_GetAddrInfoByName() which is documented to be equivalent
> to
> getaddrinfo(). I'll take care of that today.
OK, great.
> It looks like we're very close! I still would like to implement
> access
> wildcards for IPv6 addresses before we release anything, it would be
> nice to get all of teh core components listening on IPv6 and, as you
> have said, some IPv6-specific testing is in order.
*nod* - sounds good. I have some rpm upgrade testing still to get done
as well, there's still some lurking fallout from config file movement I
believe, but yep looks like we're getting close.
Its OK to defer some of those last IPv6 items to 3.6.12 too. Given this
release has taken awhile now, at this stage I think focussing on getting
something releasable would be ideal. Lets aim for a merge-to-dev later
today (my time, once down to zero QA fails), a day or two there for Ken
and others to sneak in some additional testing if we're lucky, and for
any of the remaining IPv6 work you're comfortable adding still. Then
begin release tagging, building/packaging/distro updates, etc, towards
the end of Wednesday or Thursday?
cheers.
--
Nathan
|