$new_domain_name in make_resolv_conf() in /etc/dhcpcd/dhcpcd.sh somehow contained a NUL-byte which would be printf'd to resolvconf in line 73. This caused =net-dns/resolvconf-gentoo-1.4's /sbin/resolvconf in line 46, function echo_resolv() to output "Binary file interfaces/eth0 matches" which would eventually end up in /etc/resolv.conf rendering ns lookups unusable Reproducible: Always Steps to Reproduce: 1. dhcpcd eth0 -t 8640000 2. sleep 30 3. cat /etc/resolv.conf Actual Results: # Generated by resolvconf Binary file /etc/resolvconf/run/interfaces/eth0 matches Expected Results: # Generated by resolvconf nameserver 10.0.0.1 I can't reproduce if this happenes everywhere, as I am on vacation, but this didn't happen with =net-misc/dhcpcd-3.2.3. It doesn't matter if I connect wired or wireless. I circumvented the problem by replacing /etc/resolvconf's line 46 grep "." "${IFACEDIR}/$1" with sed 's/^search \x00$//' "$IFACEDIR/$1" | grep "." in function echo_resolv() which works for me. Alternatively one could filter out the NUL in make_resolv_conf() in /etc/dhcpcd/dhcpcd.sh in function make_resolv_conf() or at it's source where the setenv new_domain_name happens (which I didn't track down). Possibly other environment variables are affected, too.
Could you attach a packet capture (tcpdump -s 0 -w /tmp/capture -i eth0) or a wireshark trace of this happening please? This *may* have been fixed in beta3 which is now out.
Or attach /var/lib/dhcpcd/dhcpcd-eth0.lease from the lease that causes this error.
[14:33] <rsmarples> dberkholz (or anyone with a bugzie dev account): be a darling and close bugs #215295, #216005, #217666 and #222381 as dhcpcd-4 is now in stable and closes those issues
