You are not logged in.
@sandstorm Did you reported it upstream?
It may be just WICD problem. I tried to find a dhcpcd 6.9.1 with networkmanager and nmcli, and it works.
Well I have the same problem (resolv.conf being void when booting) and I don't use Wicd, neither wifi on this PC.
But the problem is (by me at least) random. Sometimes it works, sometimes not.
Last edited by kero (2015-08-18 09:12:54)
Offline
It seems to be fixed by that commit. I made sure to run dhcpcd on different
interfaces (so that it would write new /etc/resolv.conf's), and it did the
right thing each time, but it would be great if others could confirm that it is
working for them. Here's an updated PKGBUILD to save a little typing:
I downloaded 2a1546e586, placed it in the src directory and ran makepkg.
I have wicd. There is no difference, resolv.conf is still empty.
Best regards
Martin
Offline
I made a binary package with change [2a1546e586] http://pkgbuild.com/~anatolik/attic/
Does upstream plan to make a new maintenance release?
Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster
Offline
Do you mean Roy? He commented the following on the ticket and closed it.
I think this is already resolved in the latest trunk - can you clarify please?
Offline
I downloaded 2a1546e586, placed it in the src directory and ran makepkg.
I have wicd. There is no difference, resolv.conf is still empty.Best regards
Martin
After installing the resulting package, did you try dhcpcd on different
interfaces? I've been using this all week without issue on two different
machines that were initially affected. Anyway, try running it on a different
interface (which should trigger writing of a (nonempty!) /etc/resolv.conf), and
then switching back to your original interface.
PS: to make absolutely certain we're on the same page, note that the checksum
in the PKGBUILD has been updated to match the tarball I used.
Offline
Here is what I did. I worked in /tmp and downloaded dhcpcd-2a1546e586 to /tmp
cp -R /var/abs/core/dhcpcd/ /tmp/
mv dhcpcd-2a1546e586 dhcpcd/src/
cd dhcpcd
makepkg
su pacman -U --force dhcpcd-6.9.1-1-x86_64.pkg.tar.xz
su systemctl daemon-reload
su systemctl restart dhcpcd
I disconnect eth0 and enable wireless in wicd. Empty resolv.conf
Offline
dhcpcd-6.9.2 has now been released to resolve this issue. Hopefully someone can update it in Arch soon!
Offline
dhcpcd-6.9.2 has now been released to resolve this issue. Hopefully someone can update it in Arch soon!
But 6.9.2 only contains a fix for compiling of dhcpcd on BSD. Was this the issue?
http://roy.marples.name/projects/dhcpcd … .9.2&n=200
Offline
That only shows the commit which was tagged as the final change in 6.9.2.
To see a list of changes, here is a better URL:
http://roy.marples.name/projects/dhcpcd … 7ae99aeae9
Offline
Just pushed 6.9.2 to [testing] repo. Please verify this version fixes the issue for you.
Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster
Offline
Just pushed 6.9.2 to [testing] repo. Please verify this version fixes the issue for you.
Just installed 6.9.2 from core. Unfortunately it did not solve the issue.
I had to downgrade to 6.9.0 to get my network working again.
Did it solve the issue for someone?
Last edited by sandstorm (2015-08-22 20:50:52)
Offline
anatolik wrote:Just pushed 6.9.2 to [testing] repo. Please verify this version fixes the issue for you.
Just installed 6.9.2 from core. Unfortunately it did not solve the issue.
I had to downgrade to 6.9.0 to get my network working again.
Did it solve the issue for someone?
So far you're the only person who has said it hasn't fixed the issue (from people that have been testing the trunk).
Can you give me any more information please, such as exactly how dhcpcd is being started and your dhcpcd.conf?
ps ax | grep dhcpcd
would help as well to see this.
Offline
FWIW I've been following this issue as dhcpcd connections were sporadic and shortlived, but the 6.9.2 upgrade has everything working fine again.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
That's good to know, thanks Trilby!
Offline
So far you're the only person who has said it hasn't fixed the issue (from people that have been testing the trunk).
Can you give me any more information please, such as exactly how dhcpcd is being started and your dhcpcd.conf?ps ax | grep dhcpcd
would help as well to see this.
Thanks smarples. I could reproduce the issue. I have the issue with my laptop.
When I am connected via Ethernet everything works fine. resolv.conf is populated and I have an IP.
When enabling wireless, I have the same issues as before. resolv.conf is empty.
I have the standard dhcpcd installation and conf files. I did not make any changes.
ps ax | grep dhcpcd
390 ? Ss 0:00 /usr/bin/dhcpcd -q -b
/etc/resolv.conf when I am using Ethernet
# Generated by resolvconf
domain lan
nameserver 192.168.2.1
/etc/resolv.conf when I activated wireless
# Generated by resolvconf
/etc/dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private
# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname
noipv4ll
Offline
OK.
When you enable wireless with the blank resolv.conf, is the ethernet still connected or not?
Can you also post the output of `dhcpcd -U wlan0` when the wireless is connected please? Replace wlan0 with the name of your wireless card.
EDIT: You also have resolvconf installed - could you report the resolvconf version please?
Last edited by rsmarples (2015-08-23 11:50:07)
Offline
Thanks for the support! No the Ethernet is not connected.
But I also tried it with Ethernet connect. Wireless does not connect and wicd re-activates the Ethernet connection which works.
Do I get an output when wireless is not connected?
# dhcpcd -U wlp2s0
wlp2s0: dhcp_dump: No such file or directory
wlp2s0: dhcp6_dump: No such file or directory
I also need to correct my statement from before. After I reconnected the Ethernet cable, I need to restart the dhcpcd service in order to get it work.
It is really strange ...
Offline
Sorry for bothering, I found the solution! I had problems because I once disabled ipv6 in /etc/sysctl.d/40-ipv6.conf
After disabling the line and rebooting everything works fine. I think I will observe the behavior and mark this topic as solved.
Should I add an entry to a wiki page?
# Disable IPv6
net.ipv6.conf.all.disable_ipv6 = 1
Offline
And I actually had another problem: somehow the dhcpcd service was enabled manually instead of letting wicd do it.
If you face the same issues, make sure you disable the dhcpcd service on all interfaces when running wicd.
systemctl disable dhcpcd.service
Solved ... thanks all!
Offline
OK, I can explain this now
1) wicd doesn't understand IPv6 - if dhcpcd forks on a working IPv6 connection before a working IPv4 connection is up then wicd thinks it has failed and tries to terminate dhcpcd.
2) wicd expects to control dhcpcd, and dhcpcd will send instructions to the master instance rather than starting a new one. So dhcpcd would fork and return OK instantly, wicd then checks for a IPv4 address on the interface, doesn't find one and then bails. Pretty similar to the 1)
Of course, you could ditch wicd and use dhcpcd-gtk or dhcpcd-qt in it's place and you wouldn't see this issue
Last edited by rsmarples (2015-08-24 09:22:15)
Offline
Thanks! That sounds reasonable. But with IPv6 it was the other way round. After enabling IPv6 I got it working "a bit".
My network configuration worked for the whole year. Only with the update of dhcpcd I got issues.
Funny coincidence :-)
Offline
@rsmarples: I think you convinced me to install NetworkManager over wicd. I cannot remember why I preferred wicd.
But NetworkManager works fine and has some additional configuration options (e.g. IPv4 and IPv6).
Offline
Awwww, I can't convince you to use dhcpcd-gtk or dhcpcd-qt?
Smaller, lighter ..... better is subjective as they both mostly work
Offline
Good point. I always look for light-weight solutions to save computing resources.
Would this be the https://aur.archlinux.org/packages/dhcpcd-ui/ package?
Offline
Yes.
I don't know how well it works in Arch though .... YMMV
Offline