You are not logged in.
Pages: 1
Hello everyone,
I have been trying to troubleshoot this problem for quite some time now, but I can't seem to be able to get to the bottom of it, so here is the summary, in the hopes of someone helping me:
Description: dhcpcd can't acquire an IP address using a wired connection (directly connected to a cable modem)
Some additional information:
My ISP has MAC-based authorization, so I spoofed the MAC address of my other home computer (this didn't cause the problem, however, it was present from the beginning).
Also, dhclient works flawlessly, and it is the current method I use to connect to the internet, but I would still be interested in finding a solution to this problem.
The computer is a Lenovo Y580 notebook.
For the sake of completion: there was no network manager, other DHCP service, etc. running while I did these tests.
So here is the log of the standard dhcpcd execution:
dhcpcd -d enp2s0
dhcpcd[2984]: version 6.1.0 starting
dhcpcd[2984]: enp2s0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' PREINIT
dhcpcd[2984]: enp2s0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' CARRIER
dhcpcd[2984]: enp2s0: using ClientID 01:f4:6d:04:ac:40:3f
dhcpcd[2984]: enp2s0: soliciting a DHCP lease
dhcpcd[2984]: enp2s0: sending DISCOVER (xid 0xd4eea2dc), next in 3.05 seconds
dhcpcd[2984]: enp2s0: sending DISCOVER (xid 0xd4eea2dc), next in 8.02 seconds
dhcpcd[2984]: enp2s0: sending DISCOVER (xid 0xd4eea2dc), next in 16.53 seconds
dhcpcd[2984]: enp2s0: sending DISCOVER (xid 0xd4eea2dc), next in 32.52 seconds
dhcpcd[2984]: timed out
dhcpcd[2984]: exited
Running it in test mode however, yields this result (the test result fields all contain the valid information for my provider, I only deleted them for privacy reasons):
dhcpcd -dT enp2s0
dhcpcd[3092]: version 6.1.0 starting
dhcpcd[3092]: enp2s0: using ClientID 01:f4:6d:04:ac:40:3f
dhcpcd[3092]: enp2s0: soliciting a DHCP lease
dhcpcd[3092]: enp2s0: sending DISCOVER (xid 0xb9bf3776), next in 3.54 seconds
dhcpcd[3092]: enp2s0: offered <clientip> from <serverip>
dhcpcd[3092]: enp2s0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' TEST
interface=enp2s0
pid=3092
reason=TEST
skip_hooks=lookup-hostname
new_broadcast_address=
new_dhcp_lease_time=
new_dhcp_message_type=
new_dhcp_server_identifier=
new_domain_name=
new_domain_name_servers=
new_host_name=
new_ip_address=
new_network_number=
new_routers=
new_subnet_cidr=
new_subnet_mask=
dhcpcd[3092]: exited
My /etc/dhcpcd.conf:
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# 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.
#duid
# Persist interface configuration when dhcpcd exits.
persistent
noipv6rs
# 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.
# Some interface drivers reset when changing the MTU so disabled by default.
#option interface_mtu
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# 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
Lspci output for my Ethernet card:
02:00.0 Ethernet controller: Qualcomm Atheros AR8161 Gigabit Ethernet (rev 08)
Subsystem: Lenovo Device 3979
Kernel driver in use: alx
Kernel modules: alx
Ethtool:
Settings for enp2s0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Current message level: 0x000060e4 (24804)
link ifup rx_err tx_err hw wol
Link detected: yes
Things that I tried:
Using various dhcpcd.conf paramters, including:
Commenting out "require dhcp_server_identifier" (as advised on the Wiki)
Disabling IPv6: noipv6rs
Switching between clientid and duid
Enabling/disabling ipv4ll
Running dhcpcd with basicly no hooks to execute
Upgrading to the newly released dhcpcd 6.2.1, which yields the same result
Any help would be appreciated, thank you for your time
Last edited by Gustorn (2014-01-20 05:43:49)
Offline
Argh, the same thing happened to me this morning but I haven't been able to pin it down. I have an Intel ethernet card though. I'm fairly sure that the problem is on my computer and not the connection, though, because all of my coworkers connect without problems. I have no new data to add to your analysis though.
I'm keeping my eye on this thread.
Offline
I had exactly the same problem at my work place (but it worked with my home network). Turns out all possible IP addresses were already reserved. After the administrator freed some up it worked again.
Offline
I can't really see that happening in my case: I have no problem getting an IP address from my ISP using other methods (dhclient, using an other OS, or even just running dhcpcd in test mode). If anyone else has an idea, or faced this problem before and managed to solve it, then please don't hesitate to share. I tried to analyze the problem even further, and I'm even considering trying to try and debug dhcpcd manually, but unfortunately I don't have the time for that right now.
Offline
Not a solution, but another data point and a possible work around. Have you tried dhclient instead of dhcpcd? I have found situations where dhclient is a bit more tolerant of networks that don't quite meet all the standards.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Yes, as I said, dhclient actually works without any problems, but I was still curious about what causes the issue in the first place. I am using dhclient as a dhcpcd replacer for now, but it'd be still nice to know. From what I've gathered it has to fail somewhere around the interface configuration, since running it with the -T flag (test mode, DHCP negotiation only) works fine.
Last edited by Gustorn (2014-01-23 16:58:12)
Offline
Yes, as I said, dhclient actually works without any problems, .
I missed that. That is what I get for posting in the early AM.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Pages: 1