Description of problem: dhclient sends FQDN as a host name in DHCP request. this is a violation of the spec and makes ddns brake down Version-Release number of selected component (if applicable): dhclient-4.2.0-6.fc14.x86_64 How reproducible: always Steps to Reproduce: 0. I assume that a machine is installed with a FQDN, configured in /etc/sysconfig/network: HOSTNAME=stinkpad.example.com 1. configure an interface to use dhcp, example: TYPE=Ethernet BOOTPROTO=dhcp ONBOOT=yes DEFROUTE=yes IPV4_FAILURE_FATAL=yes IPV6INIT=yes IPV6_AUTOCONF=no IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no PEERDNS=yes PEERROUTES=yes 2. on a different machine on the same LAN segment, start wireshark and configure its filter as 'bootp.dhcp == 1' 3. start a live trace in wireshark 4. bring up the interface on the first machine Actual results: dhclient sends a FQDN as the hostname Expected results: either one of: 1 dhclient sends a FQDN as the FQDN option 2 dhclient sends the (scrubbed) hostname as the hostname Additional info: the configured hostname must either be scrubbed or when it is a FQDN then a different dhcp req option must be used (FQDN) in pseudo code: 1. if HOSTNAME is FQDN then make dhclient use FQDN request option else make dhclient use host name request option 2. if HOSTNAME is FQDN then scrubbed = take first part of HOSTNAME else scrubbed = HOSTNAME fi make dhclient use host name request option with value 'scrubbed' according to the spec, 1 is more correct because then the client can decide to update its own DNS if it is not in its own domain, also the DNS then only sets up a PTR record instead of an A record. see man dhcpd.conf
Created attachment 490767 [details] patch to fix the issue
The initscripts code only sends DHCP_HOSTNAME if it's set; that's up to the admin to set correctly. So I'm not sure why your change would be needed.
I know, but it appears that somewhere in the chain (I suspect dhclient) that $(hostname) is sent. I suspect dhclient of being 'smart'. I looked in the code for dhclient to see if I could find it but was horrified by the totally unreadability of it and backed off again. I have seen this behaviour of fresh installs of both F14 and F15 at least.
Ok, first of all we should know if there's NetworkManager involved. If yes, than it's probably NM issue (bug #488975 is a good start). Otherwise I agree with Bill that the hostname is sent only when DHCP_HOSTNAME is set. In that case (there's no NM) please check: - that there's no DHCP_HOSTNAME set in /etc/sysconfig/network or /etc/sysconfig/network-scripts/ifcfg-ethx - that there's no hostname set in /etc/dhcp/dhclient.conf - how initscripts run dhclient (ps aux | grep dhclient)
Note that a 'default' install of F14/F15 implies that NetworkManager is active.
Ok, I did a fresh install of F15 Alpha. ----------------------------------------------- fresh F15 Alpha (works ok, no hostname is sent) ----------------------------------------------- eth0 Link encap:Ethernet HWaddr 00:1E:37:88:B3:30 inet addr:192.168.181.247 Bcast:192.168.191.255 Mask:255.255.224.0 inet6 addr: fe80::21e:37ff:fe88:b330/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:26169 errors:0 dropped:0 overruns:0 frame:0 TX packets:15204 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:38340546 (36.5 MiB) TX bytes:1111677 (1.0 MiB) Interrupt:20 Memory:fe000000-fe020000 # ps aux | grep dhclient root 1229 0.0 0.3 85924 7256 ? S 14:03 0:00 /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-eth0.pid -lf /var/lib/dhclient/dhclient-5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03-eth0.lease -cf /var/run/nm-dhclient-eth0.conf eth0 ------------------------------- Did an update and now it fails: ------------------------------- eth0 Link encap:Ethernet HWaddr 00:1E:37:88:B3:30 inet addr:192.168.181.247 Bcast:192.168.191.255 Mask:255.255.224.0 inet6 addr: fe80::21e:37ff:fe88:b330/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1354 errors:0 dropped:0 overruns:0 frame:0 TX packets:1161 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1538389 (1.4 MiB) TX bytes:124176 (121.2 KiB) Interrupt:20 Memory:fe000000-fe020000 # ps aux | grep dhclient root 2062 0.0 0.1 85956 7280 ? S 15:32 0:00 /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-eth0.pid -lf /var/lib/dhclient/dhclient-5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03-eth0.lease -cf /var/run/nm-dhclient-eth0.conf eth0 /var/run/nm-dhclient-eth0.conf ------------------------------ # Created by NetworkManager send host-name "leto.internal.hupie.com"; # added by NetworkManager option rfc3442-classless-static-routes code 121 = array of unsigned integer 8; option ms-classless-static-routes code 249 = array of unsigned integer 8; option wpad code 252 = string; also request rfc3442-classless-static-routes; also request ms-classless-static-routes; also request wpad; also request ntp-servers; # yum list NetworkMan* Installed Packages NetworkManager.x86_64 1:0.8.998-2.git20110406.fc15 NetworkManager-glib.x86_64 1:0.8.998-2.git20110406.fc15 NetworkManager-gnome.x86_64 1:0.8.998-2.git20110406.fc15 NetworkManager-openconnect.x86_64 0.8.1-7.git20110326.fc15 NetworkManager-openvpn.x86_64 1:0.8.998-1.git20110405.fc15 NetworkManager-pptp.x86_64 1:0.8.998-1.fc15 NetworkManager-vpnc.x86_64 1:0.8.998-1.git20110405.fc15 ---------- Conclusion ---------- So clearly this is a NM problem, and a major one at that! There doesn't seem to be a dhcp-options (5) option to send a FQDN so NM must scrub the hostname it sends (hostname -s). However, one might also argue that dhclient needs to do that itself, or that it must detect that the host name to send is actually a FQDN and then use the FQDN request field i.s.o. the hostname field in the DHCP request. Either way it must be solved because now the spec is violated and DDNS is non-functional.
BTW. I find the solution that is currently implemented rather unwanted: if the hostname changes (for whatever reason) then The Right Thing is NOT automatically done, the old hostname is still sent by dhclient since that is in the run file.
I think I'd prefer the solution as proposed by my patch since then The Right Thing is 'always' done. Which also implies that either the send-hostname functionality in NM must be removed (preferred) or adjusted to scrub the hostname (non preferred). I can however not oversee the implications for removing it from NM, so I'll leave that up to you guys :-) The disadvantage for keeping this in NM is what I mentioned in comment 7.
see also https://bugzilla.redhat.com/show_bug.cgi?id=540887 https://bugzilla.redhat.com/show_bug.cgi?id=488975 I'd _really_ like to see a text box in the interface dialog in NM in which I can configure the DHCP_HOSTNAME... also because having the eth and wlan interfaces send the same hostname is *not* optimal, what should be done about that?
(In reply to comment #6) > So clearly this is a NM problem, and a major one at that! > > There doesn't seem to be a dhcp-options (5) option to send a FQDN so NM must > scrub the hostname it sends (hostname -s). AFAICT there's a fqdn.fqdn option which is sent when the dhclient is started with -F switch. You do that in your patch so can you confirm that this (sending FQDN in fqdn.fqdn option) works with DDNS in your environment ? > However, one might also argue that dhclient needs to do that itself, or that it > must detect that the host name to send is actually a FQDN and then use the FQDN > request field i.s.o. the hostname field in the DHCP request. I'm not sure about this. dhcp-options(5) says to 'host-name' option that: "The name may or may not be qualified with the local domain name (it is preferable to use the domain-name option to specify the domain name)."
(In reply to comment #10) > (In reply to comment #6) > > So clearly this is a NM problem, and a major one at that! > > > > There doesn't seem to be a dhcp-options (5) option to send a FQDN so NM must > > scrub the hostname it sends (hostname -s). > AFAICT there's a fqdn.fqdn option which is sent when the dhclient is started > with -F switch. You do that in your patch so can you confirm that this (sending > FQDN in fqdn.fqdn option) works with DDNS in your environment ? > it does, hence the patch. however, I will test it again tomorrow, today I have no more time > > However, one might also argue that dhclient needs to do that itself, or that it > > must detect that the host name to send is actually a FQDN and then use the FQDN > > request field i.s.o. the hostname field in the DHCP request. > I'm not sure about this. dhcp-options(5) says to 'host-name' option that: > "The name may or may not be qualified with the local domain name (it is > preferable to use the domain-name option to specify the domain name)." ok, so then we must force NM to scrub the hostname (hostname -s) I still prefer my patch, see comment 8
(In reply to comment #11) > > > However, one might also argue that dhclient needs to do that itself, or that it > > > must detect that the host name to send is actually a FQDN and then use the FQDN > > > request field i.s.o. the hostname field in the DHCP request. > > I'm not sure about this. dhcp-options(5) says to 'host-name' option that: > > "The name may or may not be qualified with the local domain name (it is > > preferable to use the domain-name option to specify the domain name)." > > ok, so then we must force NM to scrub the hostname (hostname -s) I don't think so. I've just suggested to use (if you verify that it works) fqdn.fqdn option. so in your pseudo code it would be (for NM): 1. if $HOSTNAME is FQDN then echo send fqdn.fqdn $HOSTNAME; > /var/run/nm-dhclient-eth0.conf else echo send host-name $HOSTNAME; > /var/run/nm-dhclient-eth0.conf
sorry, it took a bit longer. results (on F15): setting in /var/run/nm-dhclient-eth0.conf: send fqdn.fqdn "host.example.com"; does NOT make dhclient send the fqdn.fqdn option then man dhcp-options say that it should have a dot at the end, so now setting in /var/run/nm-dhclient-eth0.conf: send fqdn.fqdn "host.example.com."; ALSO does NOT make dhclient send the fqdn.fqdn option so I guess it's back to square one. I'm still pushing my patch ;-)
(In reply to comment #13) > setting in /var/run/nm-dhclient-eth0.conf: > send fqdn.fqdn "host.example.com."; Yes, there has to be a dot. > ALSO does NOT make dhclient send the fqdn.fqdn option I think NM overwrites the conf file everytime you restart the interface/NM/dhclient so you probably can't test it this way. But setting the 'send fqdn.fqdn "...";' in /etc/dhcp/dhclient.conf and running 'dhclient -d eth0' manually makes dhclient send the 'Client Fully Qualified Domain Name' option in my case so I believe it will work with NM too. > I'm still pushing my patch ;-) :-) your patch looks correct but it's patch for initscripts and we are dealing with NM here. As stated in comment #2 we don't need to patch initscripts. The code that your patch changes is not executed (AFAICT) when NM is active so your patch doesn't affect how NM runs dhclient.
Created attachment 493145 [details] updated patch
(In reply to comment #14) > I think NM overwrites the conf file everytime you restart the > interface/NM/dhclient so you probably can't test it this way. > But setting the 'send fqdn.fqdn "...";' in /etc/dhcp/dhclient.conf and > running 'dhclient -d eth0' manually makes dhclient send the 'Client Fully > Qualified Domain Name' option in my case so I believe it will work with NM too. I know. I disabled NM and started dhclient by hand, but somehow it did not send the fqdn. Maybe I missed something. well. > > I'm still pushing my patch ;-) I updated the patch to be simpler. > :-) your patch looks correct but it's patch for initscripts and we are dealing > with NM here. > As stated in comment #2 we don't need to patch initscripts. I think we do. My patch is actually independent of NM: the ifup-eth script only looks at the env variables of the relevant ifcfg-* file, and if DHCP_HOSTNAME is _not_ set in that file then it forces dhclient to do the correct thing. maybe retarget this bug to initscripts then? and clone it for NM? > The code that your patch changes is not executed (AFAICT) when NM is active > so your patch doesn't affect how NM runs dhclient. I think it is but now you make me doubt it. Doesn't really affect my argument though.
(In reply to comment #16) > > As stated in comment #2 we don't need to patch initscripts. > > I think we do. > > My patch is actually independent of NM: > the ifup-eth script only looks at the env variables of the relevant ifcfg-* > file, and if DHCP_HOSTNAME is _not_ set in that file then it forces dhclient to > do the correct thing. Yes, but only when the interface is initscripts controlled. When it is NM controlled your code is not executed (my tests confirm that). > maybe retarget this bug to initscripts then? > and clone it for NM? I think that this bug is about that NM started dhclient sends FQDN in host-name option. So it's NM bug which your patch AFAICT doesn't help to solve. My suggested solution for NM is in comment #12. If you still want to push your patch into initscripts you should create another bug against initscripts but I guess you'll get another comment #2.
> Yes, but only when the interface is initscripts controlled. > When it is NM controlled your code is not executed (my tests confirm that). ok. > I think that this bug is about that NM started dhclient sends FQDN in host-name > option. So it's NM bug which your patch AFAICT doesn't help to solve. agreed > My suggested solution for NM is in comment #12. aggreed > If you still want to push your patch into initscripts you should create another > bug against initscripts but I guess you'll get another comment #2. ok, created https://bugzilla.redhat.com/show_bug.cgi?id=697877 thanks!
see also https://bugzilla.redhat.com/show_bug.cgi?id=697877
(In reply to comment #12) > 1. > if $HOSTNAME is FQDN then > echo send fqdn.fqdn $HOSTNAME; > /var/run/nm-dhclient-eth0.conf > else > echo send host-name $HOSTNAME; > /var/run/nm-dhclient-eth0.conf Wouldn't it be far simpler to just always send the shortened version as 'host-name'? This avoids exercising different code paths in dhcp servers/dhclient based on how the user sets his local host name.
It would sure be easier. However.... The documentation for DDNS says that a client can send its FQDN so that when it is not in its own domain, it can update the DNS for its own domain by itself instead of letting the DHCP server handle that. I know this is a rather 'I know none who uses this (yet)' scenario, but always sending the short version blocks this scenario.
Jiri: one problem is see is that "send host-name" appears to be mutually exclusive with "send fqdn.fqdn" right? How is the client supposed to know which one to send, and why can't the DHCP server do the right thing if both get sent?
spec say 'send host-name OR fqdn.fqdn' dhclient (NM) needs to decide what to send. server responds differently depending on what is sent, tried to explain that in comments above. my proposal was to send fqdn.fqdn when $(hostname) is FQDN but I think Jiri wanted to always send host-name. But I do think that Bill, Jiri and yourself should have a chat to decide what to do: NM and initscripts need to do things consistently :-)
(In reply to comment #22) > Jiri: one problem is see is that "send host-name" appears to be mutually > exclusive with "send fqdn.fqdn" right? How is the client supposed to know > which one to send, and why can't the DHCP server do the right thing if both get > sent? When I set both "send host-name xxx" and "send fqdn.fqdn yyy" in dhclient.conf then both options are sent. But I can't tell what does the server when it gets both options. I think that the biggest (I'm afraid the only one) DDNS expert here is Ferry and he also has the environment to test this. But I think it's NM who needs to decide what to send. (In reply to comment #23) > spec say 'send host-name OR fqdn.fqdn' What is the spec you are mentioning ? Some RFC or any other document you can point us to ? > my proposal was to send fqdn.fqdn when $(hostname) is FQDN but I think Jiri > wanted to always send host-name. Actually I was proposing (comment #12) the same. > But I do think that Bill, Jiri and yourself should have a chat to decide what > to do: NM and initscripts need to do things consistently :-) Well Bill seems to already decided (bug #697877) for "always send host-name" solution. So I would rather go the same way (i.e. solution number 2 from comment #0) in NM even it's not completely kosher (comment #21).
Created attachment 497863 [details] Remove domain part from hostname when sending as dhclient 'host-name' option This send 'host-name' as before, but removes domain part from the string if present. Does it look OK to you?
Looks good to me.
(In reply to comment #25) > Created attachment 497863 [details] > Remove domain part from hostname when sending as dhclient 'host-name' option > > > This send 'host-name' as before, but removes domain part from the string if > present. Does it look OK to you? Fine to me as well; please push upstream to git master and NM_0_8, thanks!
Pushed: 573757331487ece02d8e13c5c5643762978af0e6 (master) 64dfce29d2f1611b02af39a0e14b46a55fba2cf2 (NM_0_8)
NetworkManager-0.8.999-3.git20110526.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/NetworkManager-0.8.999-3.git20110526.fc15
Package NetworkManager-0.8.999-3.git20110526.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing NetworkManager-0.8.999-3.git20110526.fc15' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/NetworkManager-0.8.999-3.git20110526.fc15 then log in and leave karma (feedback).
NetworkManager-0.8.999-3.git20110526.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
received the update this weekend and now only the hostname is sent. thanks guys!
NetworkManager-0.8.4-2.git20110622.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/NetworkManager-0.8.4-2.git20110622.fc14
NetworkManager-0.8.4-2.git20110622.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.