udhcpc.sh uses --now like so: eval "${x}" "${args}" --interface="${IFACE}" --now This makes it impossible to use --background as a user. Please remove --now or scan "${args}" for --background and then remove --now minor nit, if net-dns/openresolv is installed I see this when udhcpc starts: No resolv.conf for interface eth4 and when stopping eth4 /etc/resolv.conf is still configured: # Generated by udhcpc for eth4 domain transmode.se nameserver 192.168.201.2 nameserver 192.168.201.12
I do not entirely understand why you need to run in background, usually ifplugd or wpa_supplicant should be used to detect link. Please open a separate bug for the openresolv issue, please provide your exact configuration.
(In reply to Alon Bar-Lev from comment #1) > I do not entirely understand why you need to run in background, usually > ifplugd or wpa_supplicant should be used to detect link. Becuse udhcpc can mange link detect by itsleft so I don't have to use ifplugd.
(In reply to Joakim Tjernlund from comment #2) > (In reply to Alon Bar-Lev from comment #1) > > I do not entirely understand why you need to run in background, usually > > ifplugd or wpa_supplicant should be used to detect link. > > Becuse udhcpc can mange link detect by itsleft so I don't have to > use ifplugd. this is entirely different issue. you want to use udhcpc as replacement to link detection, it should support the proper notifications for service in pending state and enable it, probably also support wireless properly etc... I suggest you just use ifplugd as this configuration is much simpler.
(In reply to Alon Bar-Lev from comment #3) > (In reply to Joakim Tjernlund from comment #2) > > (In reply to Alon Bar-Lev from comment #1) > > > I do not entirely understand why you need to run in background, usually > > > ifplugd or wpa_supplicant should be used to detect link. > > > > Becuse udhcpc can mange link detect by itsleft so I don't have to > > use ifplugd. > > this is entirely different issue. you want to use udhcpc as replacement to > link detection, it should support the proper notifications for service in > pending state and enable it, probably also support wireless properly etc... > I suggest you just use ifplugd as this configuration is much simpler. This is an embedded target with no wireless I/F. I just want to have udhcp be able to get me an IP address etc. when link is detected. Just specifying --background etc in conf.d/net seems even simpler than using ifplugd: udhcpc_eth4="--background --tryagain 1 --timeout 1 --retries 10" What will ifplugd get me that udhcpc dosen't ?
(In reply to Alon Bar-Lev from comment #3) > (In reply to Joakim Tjernlund from comment #2) > > (In reply to Alon Bar-Lev from comment #1) > > > I do not entirely understand why you need to run in background, usually > > > ifplugd or wpa_supplicant should be used to detect link. > > > > Becuse udhcpc can mange link detect by itsleft so I don't have to > > use ifplugd. > > this is entirely different issue. you want to use udhcpc as replacement to > link detection, it should support the proper notifications for service in > pending state and enable it, probably also support wireless properly etc... > I suggest you just use ifplugd as this configuration is much simpler. So I had a look at ifplugd, maybe it will be better :) Not sure how restrict ifplugd to just eth4, any pointer ?
(In reply to Joakim Tjernlund from comment #5) > (In reply to Alon Bar-Lev from comment #3) > > (In reply to Joakim Tjernlund from comment #2) > > > (In reply to Alon Bar-Lev from comment #1) > > > > I do not entirely understand why you need to run in background, usually > > > > ifplugd or wpa_supplicant should be used to detect link. > > > > > > Becuse udhcpc can mange link detect by itsleft so I don't have to > > > use ifplugd. > > > > this is entirely different issue. you want to use udhcpc as replacement to > > link detection, it should support the proper notifications for service in > > pending state and enable it, probably also support wireless properly etc... > > I suggest you just use ifplugd as this configuration is much simpler. > > So I had a look at ifplugd, maybe it will be better :) > > Not sure how restrict ifplugd to just eth4, any pointer ? if ifplugd exists the netifrc will use it automatically for link detection for the interface that is started if it is wired, wpa_supplicant will be used if interface is wireless.
Maybe ifplugd will work for me but I still find it odd that udhcpc is not allowed to enter background like other dhcp clients can.
(In reply to Joakim Tjernlund from comment #7) > Maybe ifplugd will work for me but I still find it > odd that udhcpc is not allowed to enter background like other > dhcp clients can. there is a difference between using dhcp client as standalone and using within netifrc. if you want to leverage the abilities and flexibility of netifrc of managing an interface there is a specific sequence in which these utilities should be used, which is a subset of their capabilities. so either you use it using the netifrc way or you just start your own dhcp client daemon in your embedded environment. it is your call to make.
Using sys-apps/ifplugd in openrc still has its problems. Now udhcpc is started when the link comes up(good) but if the dhcp server does not reply in time, udhcpc will exit and no IP address will ever be configured. I cannot change this as udhcpc.sh forces --now Also, /lib/netifrc/sh/udhcpc-hook.sh gladly creates a /etc/resolv.conf but never removes /etc/resolv.conf when deconfigured. Using resolvconf does not change that either.
