Bug 658855

Summary: Network manager doesn't expose dhcpv4 next-server option
Product: Red Hat Enterprise Linux 6 Reporter: Radek Vykydal <rvykydal>
Component: dhcpAssignee: Jiri Popelka <jpopelka>
Status: CLOSED ERRATA QA Contact: Ladislav Jozsa <ljozsa>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: ljozsa, ovasik, rkhan, sradvan, tgraf, thozza
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: dhcp-4.1.1-35.P1.el6 Doc Type: Bug Fix
Doc Text:
Cause: dhclient obtained a lease, containing also next-server option. Consequence: dhclient was not exposing next-server option to dhclient-script environment, so NetworkManager was unable to use it. Fix: dhclient now exposes next-server option to environment. Result: NetworkManager can use next-server option from dhclient's lease.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 07:42:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 653655, 727874, 960054    
Attachments:
Description Flags
Stuff siaddr/next-server into the client script options.
none
Fixed patch for dhcp-4.1.1-34.P1.el6 none

Description Radek Vykydal 2010-12-01 14:11:01 UTC
In RHEL 6.0 (NetworkManager-0.8.1-5), next-server dhcpv4 setting is not exposed in org.freedesktop.NetworkManager.DHCP4Config.Options. We use it in anaconda to get nfs server address when getting kickstart using plain "ks" boot option, see anaconda bug #653655.

Comment 2 Dan Williams 2010-12-01 21:25:14 UTC
NM will put everything it gets from DHCP into the DHCP4Config.Options bits.  What you probably want is for NM to explicitly request that option from the DHCP server, which is something that we do want to do for a few different options.  The complication is that we need to merge in the user's explicit requests from /etc/dhcp/dhclient-eth0.conf or whatever the per-interface config file is.

Comment 3 Radek Vykydal 2010-12-02 13:35:02 UTC
(In reply to comment #2)
> NM will put everything it gets from DHCP into the DHCP4Config.Options bits. 
> What you probably want is for NM to explicitly request that option from the
> DHCP server, which is something that we do want to do for a few different
> options.  The complication is that we need to merge in the user's explicit
> requests from /etc/dhcp/dhclient-eth0.conf or whatever the per-interface config
> file is.

Thanks for explanation. I only checked in Wireshark that DHCP ACK packet contains next-server information (the IP I set on the server with line "next-server X.X.X.X" appears in Next Server IP Address: ... in Wireshark gui), but it is not in DHCP4Config.Options dict. So it seemed to me that the server is sending it without explicit request. Or am I configuring it wrongly?

Comment 4 Dan Williams 2011-02-03 21:32:54 UTC
One thing you can do to check this on an already installed machine where the DHCP server is configured to send the option...

Rename /usr/libexec/nm-dhcp-client.action to nm-dhcp-client.action.real and make nm-dhcp-client.action be a small script that just does:

#!/bin/bash
echo "\n****************" >> /tmp/dhcpenv.txt
env >> /tmp/dhcpenv.txt
nm-dhcp-client.action.real $@

(remember to set the script 700, I often forget that first time)

and then let NM complete a DHCP transaction.  Then attach the /tmp/dhcpenv.txt and we'll figure out where the problem is. It shouldn't matter that this isn't an install environment, since this is just testing the DHCP client plugin.

Comment 6 Radek Vykydal 2011-05-24 14:53:27 UTC
(In reply to comment #4)

I only checked with F15 Beta (NetworkManager-0.8.998-2.git20110406.fc15.i686). I can do it also with RHEL6 if you need.

dhcpd.conf contains these global options:

filename "linux-install/pxelinux.0";
next-server 10.34.39.2;

Options dictionary obtained via dbus:

broadcast_address: 10.34.39.255
ip_address: 10.34.39.59
routers: 10.34.39.254
dhcp_server_identifier: 10.34.39.2
domain_name_servers: 10.34.39.2
domain_name: anaconda.englab.brq.redhat.com englab.brq.redhat.com brq.redhat.com redhat.com
expiry: 1304526006
network_number: 10.34.39.0
subnet_mask: 255.255.255.0
dhcp_lease_time: 3600
dhcp_message_type: 5
filename: linux-install/pxelinux.0
time_offset: 1

The dump you asked for is:

new_subnet_mask=255.255.255.0
new_domain_name=anaconda.englab.brq.redhat.com englab.brq.redhat.com brq.redhat.com redhat.com
new_ip_address=10.34.39.59
new_network_number=10.34.39.0
interface=pci3p1
reason=REBOOT
new_expiry=1304524280
new_time_offset=1
new_dhcp_lease_time=3600
pid=27536
new_dhcp_server_identifier=10.34.39.2
PWD=/
new_routers=10.34.39.254
new_domain_name_servers=10.34.39.2
SHLVL=1
new_dhcp_message_type=5
new_broadcast_address=10.34.39.255
new_filename=linux-install/pxelinux.0
_=/bin/env

Also please see https://bugzilla.redhat.com/show_bug.cgi?id=653655#c3

Comment 7 Radek Vykydal 2011-05-27 11:38:36 UTC
If I add

also request next-server

to /etc/dhcp/dhclient-<IFACE>.conf, it gets merged into nm's .conf file, but I can see this message in NM/dhclient log:

no option named next-server in space dhcp

Comment 8 Radek Vykydal 2011-05-27 12:08:10 UTC
And indeed, next-server is not a dhcp option. So I'll have to look if/how we can get this parameter in anaconda. Seems like I am going to close this as NOTABUG in a while.

Comment 9 Dan Williams 2011-06-15 01:52:38 UTC
Would be interesting to know where next-server comes from if it's not DHCP.

Comment 10 Radek Vykydal 2011-06-15 10:02:13 UTC
It comes from dhcp, but it is not a dhcp option (RFC 2132). I was told that it is sent in siaddr field of DHCP message (see RFC 1541).

Comment 11 RHEL Program Management 2011-10-07 15:58:40 UTC
Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 12 Dan Williams 2013-02-25 23:13:09 UTC
(In reply to comment #10)
> It comes from dhcp, but it is not a dhcp option (RFC 2132). I was told that
> it is sent in siaddr field of DHCP message (see RFC 1541).

So it says that siaddr will be valid for OFFER, ACK, and NAK.  How about something like the attached patch, which is completely untested?

Comment 13 Dan Williams 2013-02-25 23:14:16 UTC
Created attachment 702551 [details]
Stuff siaddr/next-server into the client script options.

Stuff siaddr/next-server into the client script options.

Comment 14 Dan Williams 2013-02-25 23:19:29 UTC
Moving over to dhcp; I cannot find *anywhere* that dhclient currently exposes siaddr to the dhclient script.  We'll need that before we can expose it through NM.  If dhclient pushes it into the script environment, then NM will stick it in the Dhcp4Config.Options dictionary.

Comment 15 Tomáš Hozza 2013-04-02 14:18:54 UTC
I tested the patch on RHEL-6.4 guest with dnsmasq as a DHCP server.

dnsmasq was run with following options:
# dnsmasq -d --conf-file= --except-interface lo --bind-dynamic --interface virbr0 --dhcp-range=192.168.122.2,192.168.122.254 --dhcp-boot=/blabla,hostname,192.168.122.222 --log-dhcp

which means that the "next-server" option in DHCP ACK packets is set to "192.168.122.222".


When I used dhclient without patch (dhclient-4.1.1-34.P1.el6) I got the following output from NetworkManager:
# gdbus introspect --system --dest org.freedesktop.NetworkManager --object-path /org/freedesktop/NetworkManager/DHCP4Config/0 -p
node /org/freedesktop/NetworkManager/DHCP4Config/0 {
  interface org.freedesktop.NetworkManager.DHCP4Config {
    properties:
      readonly a{sv} Options = {'server_name': <'hostname'>, 'host_name': <'rhel-64-virtual'>, 'filename': <'/blabla'>, 'expiry': <'1364915249'>, 'broadcast_address': <'192.168.122.255'>, 'dhcp_message_type': <'5'>, 'dhcp_lease_time': <'3600'>, 'ip_address': <'192.168.122.224'>, 'subnet_mask': <'255.255.255.0'>, 'dhcp_renewal_time': <'1800'>, 'routers': <'192.168.122.1'>, 'dhcp_rebinding_time': <'3150'>, 'domain_name_servers': <'192.168.122.1'>, 'network_number': <'192.168.122.0'>, 'dhcp_server_identifier': <'192.168.122.1'>};
  };
};

There was no sign of "next-server" option or IP address "192.168.122.222" as expected.

When I used dhclient with patch I got the following output from NetworkManager:
# gdbus introspect --system --dest org.freedesktop.NetworkManager --object-path /org/freedesktop/NetworkManager/DHCP4Config/0 -p
node /org/freedesktop/NetworkManager/DHCP4Config/0 {
  interface org.freedesktop.NetworkManager.DHCP4Config {
    properties:
      readonly a{sv} Options = {'server_name': <'hostname'>, 'host_name': <'rhel-64-virtual'>, 'filename': <'/blabla'>, 'expiry': <'1364915290'>, 'broadcast_address': <'192.168.122.255'>, 'dhcp_message_type': <'5'>, 'dhcp_lease_time': <'3600'>, 'ip_address': <'192.168.122.224'>, 'subnet_mask': <'255.255.255.0'>, '192.168.122.222': <'192.168.122.222'>, 'dhcp_renewal_time': <'1800'>, 'dhcp_rebinding_time': <'3150'>, 'domain_name_servers': <'192.168.122.1'>, 'routers': <'192.168.122.1'>, 'network_number': <'192.168.122.0'>, 'dhcp_server_identifier': <'192.168.122.1'>};
  };
};

You can see there is a new option " '192.168.122.222': <'192.168.122.222'> ". The IP address is the one set in the "next-server" option.
I expect there should be something like " 'next_server': <'192.168.122.222'> ". After some testing I discovered that the problem seems
to be that "client_envadd()" is called with empty option prefix.


Changing "client_envadd()" call from

client_envadd (client, "", "next_server", "%s", buf);

to

client_envadd (client, "new_", "next_server", "%s", buf);

solved the problem. With the "new_" prefix I got:
# gdbus introspect --system --dest org.freedesktop.NetworkManager --object-path /org/freedesktop/NetworkManager/DHCP4Config/0 -p
node /org/freedesktop/NetworkManager/DHCP4Config/0 {
  interface org.freedesktop.NetworkManager.DHCP4Config {
    properties:
      readonly a{sv} Options = {'server_name': <'hostname'>, 'host_name': <'rhel-64-virtual'>, 'filename': <'/blabla'>, 'expiry': <'1364915767'>, 'next_server': <'192.168.122.222'>, 'broadcast_address': <'192.168.122.255'>, 'dhcp_message_type': <'5'>, 'dhcp_lease_time': <'3600'>, 'ip_address': <'192.168.122.224'>, 'subnet_mask': <'255.255.255.0'>, 'dhcp_renewal_time': <'1800'>, 'routers': <'192.168.122.1'>, 'dhcp_rebinding_time': <'3150'>, 'domain_name_servers': <'192.168.122.1'>, 'network_number': <'192.168.122.0'>, 'dhcp_server_identifier': <'192.168.122.1'>};
  };
};

Comment 16 Jiri Popelka 2013-04-02 14:31:25 UTC
Amazing Tomas, thank you !

Comment 17 Jiri Popelka 2013-04-02 14:39:41 UTC
And of course big kudos to Dan for the original patch. Thanks Dan !

Comment 18 Tomáš Hozza 2013-04-02 14:44:52 UTC
Created attachment 730817 [details]
Fixed patch for dhcp-4.1.1-34.P1.el6

Original patch with the "new_" prefix and fixed so it can be applied
on RHEL-6.4 dhcp source.

Comment 25 Ladislav Jozsa 2013-10-11 14:19:47 UTC
Verified with dhclient-4.1.1-38.P1.el6.x86_64. next-server is present in gdbus instrospect output.

# gdbus introspect --system --dest org.freedesktop.NetworkManager --object-path /org/freedesktop/NetworkManager/DHCP4Config/3
node /org/freedesktop/NetworkManager/DHCP4Config/3 {
  interface org.freedesktop.DBus.Introspectable {
    methods:
      Introspect(out s data);
  };
  interface org.freedesktop.DBus.Properties {
    methods:
      Get(in  s interface,
          in  s propname,
          out v value);
      Set(in  s interface,
          in  s propname,
          in  v value);
      GetAll(in  s interface,
             out a{sv} props);
  };
  interface org.freedesktop.NetworkManager.DHCP4Config {
    signals:
      PropertiesChanged(a{sv} arg_0);
    properties:
      readonly a{sv} Options = {'dhcp_lease_time': <'600'>, 'network_number': <'172.16.0.0'>, 'domain_name': <'example.org'>, 'ip_address': <'172.16.0.3'>, 'dhcp_message_type': <'5'>, 'dhcp_server_identifier': <'172.16.0.2'>, 'broadcast_address': <'172.16.0.255'>, 'next_server': <'172.16.0.20'>, 'subnet_mask': <'255.255.255.0'>, 'expiry': <'1381501736'>};
  };
};

Comment 26 errata-xmlrpc 2013-11-21 07:42:53 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1572.html