"dhcpd time out" prevents preferential connection to wired Ethernet.

Cbhihe · 2017-10-23 13:50:43

[4.13.8-1-ARCH on Gnome / Xorg ]

A dhcpd "time out" prevents me from getting wired connectivity.

I have disabled Gnome NetworkManager in favor of netctl.
My enabled and started / running services are:
- netctl-ifplugd@net0.service calling profile ethernet-dhcp
- netctl-auto@wifi0.service calling available profiles wifi-XY or wifi_XYZ w/ different priorities attributes.
- netctl-auto-resume@.service

I disabled dhcpcd.service to avoid "a race condition at boot with systemd-udevd trying to apply a predictable network interface name." (cit. wiki)
I also disabled dhcpcd@iface_name.service on my ether and wlan interfaces (net0, wifi0), when I enabled netctl-ifplugd@net0 thinking my profiles actually called dhcp.

# cat /etc/netctl/ethernet-dhcp
Description='Basic dhcp ethernet connection'
Interface=net0
Connection=ethernet
IP=dhcp

# Two actions are placed in /etc/netctl/interfaces/net0
#ExecUpPost="ifconfig wifi0 down" || true
#ExecDownPre="ifconfig wifi0 up"

When booting with the Ethernet cable plugged in or just going from Wifi to cable connectivity, I do not get cable connectivity.

I also launch Selektor (gui for tor exit node selection) upon login (i.e. much after network.target), but it does not seem to affect the time out issue, since the issue occurs irrespectively of whether Selektor is actually launched.

$ systemctl status netctl-ifplugd@net0
● netctl-ifplugd@net0.service - Automatic wired network connection using netctl profiles
   Loaded: loaded (/usr/lib/systemd/system/netctl-ifplugd@.service; indirect; vendor preset: disabled)
   Active: active (running) since Mon 2017-10-23 14:50:21 CEST; 16min ago
     Docs: man:netctl.special(7)
 Main PID: 4614 (ifplugd)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/system-netctl\x2difplugd.slice/netctl-ifplugd@net0.service
           └─4614 /usr/bin/ifplugd -i net0 -r /etc/ifplugd/netctl.action -bfIns

Oct 23 14:50:21 HOST ifplugd[4614]: client: Starting network profile 'ethernet-dhcp'...
Oct 23 14:50:21 HOST dhcpcd[4643]: net0: waiting for carrier
Oct 23 14:50:52 HOST dhcpcd[4643]: timed out
Oct 23 14:50:52 HOST dhcpcd[4643]: dhcpcd exited
Oct 23 14:50:52 HOST ifplugd[4614]: client: <3>DHCP IPv4 lease attempt failed on interface 'net0'
Oct 23 14:50:52 HOST ifplugd[4614]: client: <3>Failed to bring the network up for profile 'ethernet-dhcp'
Oct 23 14:50:52 HOST ifplugd[4614]: client: <3>Could not start any suitable profile
Oct 23 14:50:52 HOST ifplugd[4614]: Program execution failed, return value is 1.
Oct 23 14:50:52 HOST ifplugd[4614]: Link beat lost.
Oct 23 14:50:53 HOST ifplugd[4614]: Link beat detected.

Restarting the netctl-ifplugd@net0 service does not help.
I did read the corresponding wiki section on timeout delay being set to 0 to indicate infinite wait for a "carrier"... But does this mean I have to enable the daemon as a service ? (dhcpcd@.service.d).
Would that not be a conflicht with dhcp being called from profile ? (I know I am missing something crucial here.)

Last edited by Cbhihe (2017-10-23 14:07:30)

Lone_Wolf · 2017-10-23 14:07:40

netctl won't be affected if you make that change.

This looks like you have some low level problem with the wired connection .

for now, disable netctl-ifplugd@net0 and boot into console mode aka multi-user target .
login as root , run dhcpcd net0 and post output .

Cbhihe · 2017-10-23 15:22:36

Low level = hw ?

I disabled
gdm
netctl-ifplugd@net0
rebooted to root on console

# dhcpcd net0 2>&1 | tee output-to-keep

Produced exactly no output O_o ¿?!
EDIT
produced the following output:

net0: waiting for carrier
timed out
dhcpcd exited

Back in GDM (to write this) after reboot, I check that as before I have no IP address lease on interface net0, although it is perfectly detected.
I also note with iwconfig that my bit rate on iface wifi0 is very low: 1Mb/s
(That low bit/rate and the proxying may be entirely unrelated to the problem at hand. I add that info in case it would be meaningful).

Last edited by Cbhihe (2017-10-23 15:31:59)

Cbhihe · 2017-10-23 15:40:07

Running test with proxying disabled at boot seems to allow carrier to be detected on wire....

I don't quite understand how it is related.

Selektor loads a table of nodes and geolocations when starting. It takes more time than I initially thought. Maybe 10 to 15s. However it does so after gdm has started. So in prinicpal all networkg services should be up and running by then (i.e. netctl should have had time to do its magic before Selektor kicks in ... oder ?).

So what could be cooking there ?

Cbhihe · 2017-10-23 15:51:51

Yes, after further cheks, oce netctl has done what it does without "interference" (??) from Selektor, everything is optimal.
Meaning:
netctl-auto-ifplugd@net0 --- works
netctl-auto-resume@.service --- works too (after laptop lid close and reopen)
nettl-auto@wifi0 --- works too and choose the right prority ESSID profile

It does so after I manually switch selektor from "no proxy" to "full proxying".

Only it does not work when I boot with Selektor in "full proxy" of "proxy-by-pattern" modes, i.e. when Selektor becomes a nuisance (apparently) by loading its tor exit node table.

That is NOT satisfactory from the point of view of Torifying a box. Tor should be able to kick in from t=0 after network service are UP (at the end of level 3 and with no GUI ? ).
Maybe by having preloaded exit node table in store ? (probably ?... not?)
Advisable to post another question on how to acheive that ?

Cbhihe · 2017-10-24 11:49:36

Sorry y'all but I am back with the exact same issue as the days past, except now I boot with fully disabled proxying. So no 'tor'.

$ systemctl is-system-running
Running
$ ip a
1. lo: ...
2: net0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state DORMANT group default qlen 100
    link/ether 00:e0:4c:68:01:7e brd ff:ff:ff:ff:ff:ff
3: wifi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 9c:b6:d0:de:08:37 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.33/24 brd 192.168.1.255 scope global wifi0
       valid_lft forever preferred_lft forever
    inet6 fe80::9eb6:d0ff:fede:837/64 scope link
    valid_lft forever preferred_lft forever

shows no carrier for net0 although the RJ45 Ether cable is plugged in.

Per @Lone_Wolf 's suggestion in #2 of this thread (but proceeding from terminal), I disabled netctl-ifplugd@net0:

$ sudo systemctl disable netctl-ifplugd@net0
$ sudo dhcpcd -d net0
dhcpcd-6.11.5 starting
net0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' PREINIT
net0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' NOCARRIER
net0: waiting for carrier
timed out
dhcpcd exited

I am out of my wit here... help !

Last edited by Cbhihe (2017-10-24 11:50:17)

seth · 2017-10-24 14:07:33

No carrier means the other side isn't responding (at all)
Unless a kernel bug, this means broken Nic, Jack, Plug, Cable, Plug, Jack, Switch/Router.
Odds (by apparent nondeterministic behavior) lean to the cable/jacks by 99.8% (or so - the number is totally made up) iow before anything else: replace the cable.
If that doesn't help, check the actual hardware for that device (for known issues) and your switch/router logs - elaborate on the actual HW setup in general.

Cbhihe · 2017-10-24 15:02:43

Mmmh ...(?) Tx for replying Seth.

HW is brand new XPS 9560 fresh out of the box from 2 months ago.
The wire-NIC is a USB-RJ45 dongle. Brand new as well and tested on 2 other boxes: no fail but that's hardly statistically significant.
Dongle is Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter.

Everything HW checks so (if you are right) Cat 6 cable termination could be the culprit. It misses one the two terminals' clip to lock it in place in the corresponding female RJ45 socket. But I have used it for quite a few months now and with quite a few other boxes, so... but why not.
I will change it though before I recrimp it with a new RJ45 terminal.

[now working with new cable ...]

On another front:
I am now become quite leery of Selektor.
I have actually disabled it completely. No launch anymore.
Instead I enabled tor with the tor daemon running as service in background.
>>> No problem there. netctl behaves quite normally at boot as well as when I switch from cable to Wifi and vice-versa.
Could it be Selektor somehow "pre-empting" the wire-NIC to do its magic and preventing it from going UP because of a dhcpcd timeout in the end ?
Would setting dhcpcd timeout to 0 be a good idea in that case ?

So while I hope someone with experience in successfully running Selektor on Arch with Gnome/Xorg is already preparing THE answer to this issue, I also am going to contact the developper at dazzleship, because I do need to be able to specify exit nodes to visit specific URLs.

Last edited by Cbhihe (2017-10-24 15:12:46)

Arch Linux

#1 2017-10-23 13:50:43

"dhcpd time out" prevents preferential connection to wired Ethernet.

#2 2017-10-23 14:07:40

Re: "dhcpd time out" prevents preferential connection to wired Ethernet.

#3 2017-10-23 15:22:36

Re: "dhcpd time out" prevents preferential connection to wired Ethernet.

#4 2017-10-23 15:40:07

Re: "dhcpd time out" prevents preferential connection to wired Ethernet.

#5 2017-10-23 15:51:51

Re: "dhcpd time out" prevents preferential connection to wired Ethernet.

#6 2017-10-24 11:49:36

Re: "dhcpd time out" prevents preferential connection to wired Ethernet.

#7 2017-10-24 14:07:33

Re: "dhcpd time out" prevents preferential connection to wired Ethernet.

#8 2017-10-24 15:02:43

Re: "dhcpd time out" prevents preferential connection to wired Ethernet.

Board footer