Bug 658855
Summary: | Network manager doesn't expose dhcpv4 next-server option | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Radek Vykydal <rvykydal> | ||||||
Component: | dhcp | Assignee: | Jiri Popelka <jpopelka> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Ladislav Jozsa <ljozsa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 6.0 | CC: | ljozsa, ovasik, rkhan, sradvan, tgraf, thozza | ||||||
Target Milestone: | rc | Keywords: | 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
Radek Vykydal
2010-12-01 14:11:01 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. (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? 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. (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 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 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. Would be interesting to know where next-server comes from if it's not DHCP. 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). 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. (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? Created attachment 702551 [details]
Stuff siaddr/next-server into the client script options.
Stuff siaddr/next-server into the client script options.
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. 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'>}; }; }; Amazing Tomas, thank you ! And of course big kudos to Dan for the original patch. Thanks Dan ! 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.
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'>}; }; }; 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 |