Hi
A few day ago I have noticed erroneous behaviour.
The box I have installed Slackware connected by twisted-pair wire directly to router. This router also works as DHCP server, and my box network configuration is fetched from it.
The problem begins when during box startup router is powered down. When dhcpcd -t 10 eth0 command works, there is no carrier on eth0 so dhcpcd successfully halts, so my box resides without network configuration forever even if router will bootup(what is definitely now what I or anybody want).
So question(and probably request to make such behaviour default in future release of Slackware): how to force dhcpcd to wait on interface until it find fetch configuration(i.e. to work in the same manner as if it fetched configuration normally)? I'm not experienced user in configuring network infrastructure so questioning here. man dhcdcd and man dhcpcd.conf does give any clues for me.

I'm not sure I understand what you're trying to do, but if you power up the machine while the router is still not up, it's obvious you're not going to get a dhcp lease. You could try increasing the dhcp timeout for the interface in /etc/rc.d/rc.inet1.conf

e.g. 1 minute

Since the router may not be powered up for a length of time, it may be better to set

which will cause dhcpcd to wait *forever* (this setting can also be made global in /etc/dhcpcd.conf)

However, this will cause the startup process to pause, waiting for the lease; if this *isn't* the desired behaviour, you can edit rc.M to cause /etc/rc.d/rc.inet1 to fork to the background.

You could also set up a cron job to run dhcpcd every x seconds to poll for a lease on that interface until successful (or to restart rc.inet1 until successful, however not wise if multiple interfaces are in use simultaneously...)

cheers,

1 members found this post helpful.

Isn't this one of the things that those 'network-manager' type of apps were written to address?

Personally, I prefer the current behaviour as I try and avoid processes that constantly poll. If that means having to issue the odd command from time to time, then so be it.

1 members found this post helpful.

Yes, but when router will power up(or accidentally unplugged connector will be connected), I want to get lease as fast as possible. I.e I want dhcpcd to hang on interface always, regardless carrier presence.
For instance, I have two interfaces eth0 & eth1.
eth0 is connected and router on other side is up.
eth1 is connected but router on other side is down(or the same, if connector is unplugged).

When running rc.inet1 during boout-up:
1) dhcpcd will get lease for eth0 interface, and there will be a process /sbin/dhcpcd -t 10 eth0 (marking as A)
2) dhcpcd will detect NO CARRIER on eth1 and shutdown itself(i.e there is will not be any /sbin/dhcpcd -t 10 eth1 (marking as B))

When on eth0 connector accidentally unplugs, or router is down - i.e. no carrier on interface, process A will wait until carrier appear and re-request lease interface.
When on eth1 connecor will be replugged(or router power up) i.e. carrier will be detected, there is no such process B to rerequest lease. So eth1 will be uninitialised forever(or at least until some admin manually restart dhcpcd for this interface).

mrclisdue
No, it is not desired behaviour. System should start regardless interface states.
cron was first solution I have considered, but then I have thought a little "WTF? Why something else should do dhcpcd's work?"

Now I have found -b switch, which forks dhcpcd immediately regardless interface, but I prefer it to fork only after first retry failed, so I will see it in boot log. Is it possible? Tried both -b -B together but it stucks on carrier detection forever.

Anyway I very disappointed why this switch does not included into rc.inet1 by default. Such state reduces usability of Slackware as out-of-box blank system for different usage cases(i.e requires one more patch need to be applied before setup other business applications).

I may be clueless, but I have thought a little "WTF? Why should Slackware do the network administrator's work?"
Your usage case seems highly artificial for a business setup. Maintaining the availability of the router and hence the DHCP server as well as the physical integrity of plug connections is not a software problem.

allend, hotplugging new device is "artificial for a business setup"?
Let imagine, I have box with 10 interfaces. Two interfaces initially used - connected router, 8 reserved for future expansion. Software which uses them is configurable in runtime, i.e. I can add new record about new interface to database(or use some other administrative interface) and software will know immediately about available direction. The last problem is dhcpcd to assign interface configuration when device will be physically connected(if take into account that box will be locate let say in GMT-7 and Administrator locate at GMT+5 I assume ability to catch up new hardware without human supervision is very powerful feature of system). And usage of root shell to manually start dhcpcd or reboot system is strictly prohibited(first - no up sshd - closed another attack direction, second - system should be 99.99999% up which is impossible when required human interaction).

Is this not hypothetical?
Is this not logically inconsistent?
Is it not poor practice to not have a remote administration facility? The chances of a successful attack on a properly configured sshd are so low as to be practically negligible.

I see what you are trying to do. You want to setup an automated failover system. That is an admirable aim. However, I do take issue with you expecting that this should be available to you out of the box with no effort on your part. It is impossible to provide solutions to all scenarios.

I think if the router is powered down, there would be no carrier, essentially as if the cable was not plugged in. An app like ifplugd or netplug should solve the problem for this weird corner case, IMHO.