Yeah, I wrote in my first post that I was reading the inet files, but that they failed to inspire me. It was things like this:
Code:
echo "Polling for DHCP server on interface ${1}:"
# If you set a timeout, you get one, even if the kernel doesn't think that
# your device is connected, in case /sys isn't right (which it usually isn't
# except right after the device is loaded, when it usually is):
These things are exactly why I love Slackware, and why I'm glad I'm back. But it kind of tells me that the time-out setting is a form of 'manual override' that can be set because the automagicly detected status can under certain circumstances be wrong.
Code continues:
Code:
if [ "${DHCP_TIMEOUT[$i]}" = "" ]; then
ifconfig ${1} up && sleep 1
CONNSTATUS="$(cat /sys/class/net/${1}/carrier 2> /dev/null)"
ifconfig ${1} down
if [ "$CONNSTATUS" = "0" ]; then
# The kernel has just told us the cable isn't even plugged in, but we will
# give any DHCP server a short chance to reply anyway:
echo "No carrier detected on ${1}. Reducing DHCP timeout to 10 seconds."
DHCP_TIMEOUT[$i]=10
fi
As above. This doesn't bring me closer to a /fast/ solution. It does help understanding why things are as they are, and yes, also, that it may be changed by hand.
But somehow that didn't seem the right approach.
The way I understand it, and correct me if I'm wrong, but a hard coded time-out counts as a manual override. But the lack of a hard coded time-out might yield false negatives (the machine thinks there is no signal while there is a signal).
Now if I where to take this approach in solving this minor problem, I would have to run some tests (cuz I trust myself least of all before testing). That means pulling the cable and seeing whether...
Code:
cat /sys/class/net/${1}/carrier # Where ${1} = eth0
...yields different results with the cable in and out. (It does, instantly
)
So that gives some results to work with, and has taught me just a little more about the system, but also gave me the idea that I'd be working on a complex approach to solving what is basically not even a problem but an optimization. So rather than following this road I did a little comparative study
and found this:
The working code of Slackware
Code:
/sbin/dhcpcd -d -t ${DHCP_TIMEOUT[$i]:-30} ${DHCP_OPTIONS} ${1}
The working code of Backtrack:
Code:
/sbin/dhcpcd -t 60 $eth &
See the difference?? Heheh... it's all so logical once you've seen it. In fact, moving the whole thing to the background was one of my first thoughts (OP). But I'm so easily distracted that I didn't stop to think about it until after I compared Backtrack's inet scripts with those of Slackware.
Thanks for answering y'all!
Sorry about the long posts
