Bug 658855 - Network manager doesn't expose dhcpv4 next-server option
Network manager doesn't expose dhcpv4 next-server option
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: dhcp (Show other bugs)
6.0
Unspecified Unspecified
low Severity medium
: rc
: ---
Assigned To: Jiri Popelka
Ladislav Jozsa
: Patch
Depends On:
Blocks: 960054 653655 727874
  Show dependency treegraph
 
Reported: 2010-12-01 09:11 EST by Radek Vykydal
Modified: 2015-09-27 22:04 EDT (History)
6 users (show)

See Also:
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 02:42:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Stuff siaddr/next-server into the client script options. (1.73 KB, patch)
2013-02-25 18:14 EST, Dan Williams
no flags Details | Diff
Fixed patch for dhcp-4.1.1-34.P1.el6 (1.81 KB, patch)
2013-04-02 10:44 EDT, Tomáš Hozza
no flags Details | Diff

  None (edit)
Description Radek Vykydal 2010-12-01 09:11:01 EST
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 16:25:14 EST
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 08:35:02 EST
(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 16:32:54 EST
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 10:53:27 EDT
(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 07:38:36 EDT
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 08:08:10 EDT
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-14 21:52:38 EDT
Would be interesting to know where next-server comes from if it's not DHCP.
Comment 10 Radek Vykydal 2011-06-15 06:02:13 EDT
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 Product and Program Management 2011-10-07 11:58:40 EDT
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 18:13:09 EST
(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 18:14:16 EST
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 18:19:29 EST
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 10:18:54 EDT
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 10:31:25 EDT
Amazing Tomas, thank you !
Comment 17 Jiri Popelka 2013-04-02 10:39:41 EDT
And of course big kudos to Dan for the original patch. Thanks Dan !
Comment 18 Tomáš Hozza 2013-04-02 10:44:52 EDT
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 10:19:47 EDT
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 02:42:53 EST
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

Note You need to log in before you can comment on or make changes to this bug.