Re: dhcpv6-problem

[Dan Williams <dcbw redhat com>]

On Thu, 2014-07-10 at 21:31 +0200, Thomas Schäfer wrote:
> Am Donnerstag, 10. Juli 2014, 11:42:01 schrieben Sie:
> > On Sun, 2014-07-06 at 20:22 +0200, Bjørn Mork wrote:
> > > BTW, I just noticed: Linux uses the relately new UUID DUID type.  Try to
> > > change to the more common LLT DUID type, like Windows uses, and see if
> > > that helps. Lots of DHCPv6 implementations look into the DUID to get mac
> > > addresses and may very well barf on both DUID-UUID and DUID-EN.  They
> > > just don't care about the specs.
> >
> > You're probably right.  For NM + dhclient, if there is no user-specified
> > DUID in the configuration files, NM will generate a DUID-UUID (RFC 6355)
> > for privacy reasons.  To test whether this is indeed the issue, you can
> > put the following line:
> >
> > default-duid "\000\001\000\001\023=V0\000#T\304\314\203";
> >
> > (this is the dhclient escaped for of the DUID that I got from
> > zte823dhcpv6roblem2.cap for the successful run)
>
> > Let us know how that goes!
>
> It was not successful.
> I think NM took the duid, you provided. But the result is the same - time out.
>
> http://www.cis.uni-muenchen.de/~thomas/ztemf823-test-20140710.pcapng

The Client Identifier options are now exactly the same between Linux and
Windows.  The only other things are some differences in the option
request list, a client FQDN, and the Windows client sending a "Vendor
Class" option.  I'm not sure any of these would make a difference.

But just to check, you do have any firewall set to allow DHCPv6, right?
I've had that problem in the past...

Dan