Re: making DUID work .. was [Dnsmasq-discuss]

On 02/12/2013 10:53 AM, Gene Czarcinski wrote:
On 02/12/2013 10:13 AM, Gene Czarcinski wrote:
On 02/12/2013 09:23 AM, Gene Czarcinski wrote:
On 02/11/2013 04:51 PM, Dan Williams wrote:
On Mon, 2013-02-11 at 16:42 -0500, Gene Czarcinski wrote:
On 02/11/2013 04:06 PM, Dan Williams wrote:

Fedora 17 and 18, until, left the DUID behavior up to
dhcleint, which appears to generate a default DUID itself; but the
NetworkManager code will honor that existing DUID if it finds it in the interface+connection specific lease file [1]. If NM does *not*, please
let me know and we'll fix that bug.
It is *not*.

I assume that NM is suppose to be examining the lease file before
dhclient starts because it sure looks like it is dhclient that is
creating the default.

I have a real-hardware system that I can reboot or whatever so if you
need me to test something, just tell me.  I know that it is
frustrating on both sides if I say there is a problem and you cannot
reproduce it.

If you need to see the configuration file, then I should probably open
a bugzilla report and file it there.

BTW, I tried putting the default-duid in /etc/dhclient.leases and also
in /var/lib/dhclient.leases and the only thing that seems to work
is /var/lib/NetworkManager/dhclient6-<whatever>.lease
You want one of dhclient*6*.leases, in this priority order:

SYSCONFDIR "/dhclient6.leases",
LOCALSTATEDIR "/lib/dhcp/dhclient6.leases",
LOCALSTATEDIR "/lib/dhclient/dhclient6.leases",

or the interface+connection-specific leasefile, eg:


When I saw the above, hand slaps forehead ... of course it should be dhclient6.leases and not dhclient.leases.

So I changed it in both /etc/dhclient6.leases and /var/lib/dhclient/dhcleit6.leases but it still did not work. Only replacing the interface+connection-specific leasefile with the one line file specifying the default-duid works. However, I cannot see that as a NM problem and will need to investigate dhclient.

OK, so I took a look at the dhclient code and it only looks for one dhclient6 lease file. It is either the default /var/lib/dhclient/dhclient6.leases or what is specified by the -SF command line argument such as done by NetworkManager.

NetworkManager could create a new NM file such as /etc/default-duid that, if present, was use for the initial file but dhclient will do nothing to help.

From my perspective, for NetworkManager to do something like this would be useful because it could be set during the install process and the system would be configured properly from first boot.

Would the NM project be receptive to a patch which implemented something like that?

No need for a new patch! Just need to make the code that is there work. It appears to me that in dhclient.c nm_dhcp_dhclient_init() is defined but never called by anything. Therefore, priv->def_leasefile is NULL and get_duid() does not access any of the alternate locations to get the default-duid value.

I will see what kind of patch I can com up with. I am also moving this thread over to the Network Manager mailing list.

I have figured out what was incorrect (mainly that the lease file was not being saved) and will pretty up things before I support the patch. This patch fixes things so that if the specific lease file is missing or does not have a valid default-duid AND if a default-duid is specified in /etc/dhclient6.leases, /var/lib/dhcp/dhclient6.leases or /var/lib//dhclient/dhclient6.leases, then the default-duid will be written out the the lease file.

That fixes one thing. The other is a puzzling problem. If none of the above files exists, then a duid-UUID is suppose to be generated. BUT, in the logs a get the message that the /etc/machine-id could not be parsed.

I don't know about other systems but all of mine have a /etc/machine-id consisting of a string of 32 hex digits representing 16 bytes. From the man-page for uuid_parse I get:

The  uuid_parse  function converts the UUID string given by in into the
binary representation.   The  input  UUID  is  a  string  of  the form
1b4e28ba-2fa1-11d2-883f-b9a761bde3fb      (in      printf(3) format
"%08x-%04x-%04x-%04x-%012x", 36 bytes plus the trailing '\0')

And from the dbus-uuidgen man-page:

Note  that  the D-Bus UUID has no relationship to RFC 4122 and does not
generate UUIDs compatible with that spec.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]