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 _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
