dhcpcd-6.0.2 on client, dnsmasq-2.66 on server. dhcpcd called by networkmanager with "-B -K -L -G -c /usr/libexec/nm-dhcp-client.action -h flagship enp3s0" parameters. With dhcpcd-6, dnsmasq is apparently unable to extract the "hostname" parameter, leaving the client(s) unable to be found by hostname; all is well with dhcpcd 5.99.7. 5.99.7: dnsmasq-dhcp[1654]: DHCPREQUEST(eth0) 192.168.0.207 6c:f0:49:5e:70:2e dnsmasq-dhcp[1654]: DHCPACK(eth0) 192.168.0.207 6c:f0:49:5e:70:2e flagship 6.0.2: dnsmasq-dhcp[1654]: DHCPREQUEST(eth0) 192.168.0.207 6c:f0:49:5e:70:2e dnsmasq-dhcp[1654]: DHCPACK(eth0) 192.168.0.207 6c:f0:49:5e:70:2e I don't know if this is a dnsmasq or dhcpcd bug. Reproducible: Always
FYI I am seeing similar funky behavior with dhcpcd-6 against a microsoft domain controller as the DHCP server. The first reverse lookup answer here is from dhcpcd-6, strangely prefixed with \007 in the PTR record. The second answer is from the working dhcpcd-5. I have no idea what's causing this, but I though't I'd share another data point. I'm back on dhcpcd-5 for now. --------------- # dig -x 172.21.132.78 ; <<>> DiG 9.9.2-P2 <<>> -x 172.21.132.78 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11396 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;78.132.21.172.in-addr.arpa. IN PTR ;; ANSWER SECTION: 78.132.21.172.in-addr.arpa. 900 IN PTR \007ris-ben.vtaig.com. 78.132.21.172.in-addr.arpa. 900 IN PTR ris-ben2.vtaig.com. ;; Query time: 167 msec ;; SERVER: 172.16.0.3#53(172.16.0.3) ;; WHEN: Wed Jul 17 11:35:28 2013 ;; MSG SIZE rcvd: 162
Maybe the Summary should be "hostname not sent"?
I'm wondering if dhcpcd-6 is sending an invalid/corrupted hostname parameter that dnsmasq is rejecting or ignoring
I'm having the same problem. Since the upgrade the hostname is not registered with the DNS anymore. Downgrading to 5.9XXX fixes it
Possibly this upstream bug? http://roy.marples.name/projects/dhcpcd/ticket/275
The hostname is definitely in the dhcp request, twice with dhcpcd-6.
With identical options, dhcpcd-6 got a little chattier. These are dumps of the dhcp requests sent: mano@dargo ~ $ hexdump -C dh602.bin 00000000 01 01 06 00 05 6e 5a 35 00 00 00 00 00 00 00 00 |.....nZ5........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 6c f0 49 5e |............l.I^| 00000020 70 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |p...............| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 63 82 53 63 |............c.Sc| 000000f0 35 01 03 3d 13 ff 00 00 00 02 00 01 00 01 0f 2d |5..=...........-| 00000100 b8 2d 00 50 8d db 94 ba 32 04 c0 a8 00 cf 39 02 |.-.P....2.....9.| 00000110 05 dc 3c 2d 64 68 63 70 63 64 2d 36 2e 30 2e 32 |..<-dhcpcd-6.0.2| 00000120 3a 4c 69 6e 75 78 2d 33 2e 31 30 2e 31 3a 78 38 |:Linux-3.10.1:x8| 00000130 36 5f 36 34 3a 41 75 74 68 65 6e 74 69 63 41 4d |6_64:AuthenticAM| 00000140 44 0c 08 66 6c 61 67 73 68 69 70 51 0c 05 00 00 |D..flagshipQ....| 00000150 08 66 6c 61 67 73 68 69 70 37 0e 01 79 21 03 06 |.flagship7..y!..| 00000160 0c 0f 1c 2a 33 36 3a 3b 77 ff |...*36:;w.| 0000016a mano@dargo ~ $ hexdump -C dh5997.bin 00000000 01 01 06 00 19 94 6f c7 00 00 00 00 00 00 00 00 |......o.........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 6c f0 49 5e |............l.I^| 00000020 70 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |p...............| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000000e0 00 00 00 00 00 00 00 00 00 00 00 00 63 82 53 63 |............c.Sc| 000000f0 35 01 03 3d 13 ff 00 00 00 02 00 01 00 01 0f 2d |5..=...........-| 00000100 b8 2d 00 50 8d db 94 ba 32 04 c0 a8 00 cf 39 02 |.-.P....2.....9.| 00000110 05 dc 3c 2e 64 68 63 70 63 64 2d 35 2e 39 39 2e |..<.dhcpcd-5.99.| 00000120 37 3a 4c 69 6e 75 78 2d 33 2e 31 30 2e 31 3a 78 |7:Linux-3.10.1:x| 00000130 38 36 5f 36 34 3a 41 75 74 68 65 6e 74 69 63 41 |86_64:AuthenticA| 00000140 4d 44 0c 08 66 6c 61 67 73 68 69 70 37 0e 01 79 |MD..flagship7..y| 00000150 21 03 06 0c 0f 1c 2a 33 36 3a 3b 77 ff |!.....*36:;w.| 0000015d
*** Bug 477320 has been marked as a duplicate of this bug. ***
Roy, Can you take a look at this? Thanks, William
This may have been fixed in dhcpcd-6.0.3 If that can be tested (a reboot maybe required to clear the hostname) and still found at fault then I'll investigate further.
At least on my machines 6.0.3 is still broken; dnsmasq still can't find the hostname.
Can you attach the binary tcpdumps please so I can view them in wireshark?
Created attachment 353716 [details] Wireshark PCAP file of dhcpcd-6.0.3 talking to dnsmasq
The capture looks fine. Maybe an issue with dnsmasq?
dnsmasq is at fault as it doesn't support partial FQDN. Bug #477556 created for dnsmsasq, with a patch
(In reply to Roy Marples from comment #15) > dnsmasq is at fault as it doesn't support partial FQDN. > Bug #477556 created for dnsmsasq, with a patch Thanks, that worked. Given that dhcpcd is called with identical parameters, i'm curious as to what changed in dhcpcd-6 so that this bug is triggered? And there's still the issue with MS DHCP server mentioned in comment #2, which you can't fix by a patch :) Thanks again.
(In reply to Manuel Lauss from comment #16) > (In reply to Roy Marples from comment #15) > > dnsmasq is at fault as it doesn't support partial FQDN. > > Bug #477556 created for dnsmsasq, with a patch > > Thanks, that worked. Given that dhcpcd is called with identical parameters, > i'm curious as to what changed in dhcpcd-6 so that this bug is triggered? > And there's still the issue with MS DHCP server mentioned in comment #2, > which you can't fix by a patch :) The difference is that dhcpcd.conf now sends hostname and fqdn. The RFC in question says that DHCP clients SHOULD not do this. However it's not MUST so is allowed. You're right in I cannot patch MS servers. I might have to split fqdn into a DHCPv4 and DHCPv6 options as DHCPv6 has no hostname option and older DHCPv4 servers have no FQDN option.
(In reply to Roy Marples from comment #17) > (In reply to Manuel Lauss from comment #16) > > (In reply to Roy Marples from comment #15) > > > dnsmasq is at fault as it doesn't support partial FQDN. > > > Bug #477556 created for dnsmsasq, with a patch > > > > Thanks, that worked. Given that dhcpcd is called with identical parameters, > > i'm curious as to what changed in dhcpcd-6 so that this bug is triggered? > > And there's still the issue with MS DHCP server mentioned in comment #2, > > which you can't fix by a patch :) > > The difference is that dhcpcd.conf now sends hostname and fqdn. > The RFC in question says that DHCP clients SHOULD not do this. However it's > not MUST so is allowed. > > You're right in I cannot patch MS servers. > I might have to split fqdn into a DHCPv4 and DHCPv6 options as DHCPv6 has no > hostname option and older DHCPv4 servers have no FQDN option. That would be much appreciated, especially since probably a LOT of dhcp servers in that special case interpret "SHOULD" as "MUST NOT" :-)
The RFC is a bit confusing. Anyway, I've patched dhcpcd not to send FQDN by default for DHCPv4 but when sending DHCPv6 a FQDN will be sent IF DHCPv4 is sending a hostname. It also checks the FQDN setting in dhcpcd as well. http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd.git;a=commitdiff;h=2d2296a0744614401e32d09a34f39d9e96712043 I think there's a GIT based ebuild for dhcpcd in portage, try that please.
For what it's worth, dhcpcd started setting my hostnames to dhcppc0 and such since 6.0.3, while 6.0.2 still seems to work as usual (having hostname set in /etc/conf.d/hostname). The 9999 (last tested just moments ago) does what 6.0.3 does. Considering there is no configuration file changes between 6.0.2 and 6.0.3, I'm maybe guessing it isn't due to me not noticing something obvious... maybe?
Looked into the commit: a4262284bd0f9274d19e5c717e4d07dbd6f58715 on dhcpcd-hooks/30-hostname just after my comment... If I do nohook 30-hostname, it seems the old behaviour is back.
(In reply to Chiitoo from comment #21) > Looked into the commit: > > a4262284bd0f9274d19e5c717e4d07dbd6f58715 > > on dhcpcd-hooks/30-hostname just after my comment... If I do nohook > 30-hostname, it seems the old behaviour is back. Thanks for the report. That is fixed here: http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd.git;a=commitdiff;h=37128421db55b9467b123835337e1eb806785437
(In reply to Roy Marples from comment #22) > (In reply to Chiitoo from comment #21) > > Looked into the commit: > > > > a4262284bd0f9274d19e5c717e4d07dbd6f58715 > > > > on dhcpcd-hooks/30-hostname just after my comment... If I do nohook > > 30-hostname, it seems the old behaviour is back. > > Thanks for the report. > That is fixed here: > http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd.git;a=commitdiff; > h=37128421db55b9467b123835337e1eb806785437 dhcpcd-6.0.5 is released with this fix
This version has been in the tree for a while.
