Tiny Core Base > Raspberry Pi
getTime.sh fails at startup
Rich:
Hi CentralWare
--- Quote from: CentralWare on August 15, 2024, 02:37:03 AM --- ... 3. Wait for eth0/wlan0/etc. to have an active inet addr in ifconfig ...
--- End quote ---
That's what settime.sh does:
--- Code: ---CNT=0
until ifconfig | grep -q Bcast
do
[ $((CNT++)) -gt 60 ] && break || sleep 1
done
--- End code ---
CentralWare:
@Rich: We've had odd-ball instances where we have had to use iwconfig (for wireless, instead of ifconfig - but I THINK ethernet tools and drivers over the past number of years has all but eliminated that need - I haven't bothered checking/testing to know for certain) and/or cases (on WinNT networks) where a broadcast address becomes available before an actual assigned address, so our IP triggers are based on an IP (ie: 0.0.0.0, 127.x.x.x and 169.254.x.x are then ignored completely, 0 and 127 for obvious reasons unless 127's being used as a cross-over network and 169 for machines which are usually cabled directly together to Win based machines which don't offer a gateway or forwarding service) so this is just our way of covering all the bases WE know of historically, especially when using multiple NICs, unless DHCP Client is launched manually per device and nodhcp is used (Core) to help prevent WinNT temporary assignments or even mis-assignments on multi-homed networks. (To each their own? Agree to disagree? Artistic Nerd License? Ridiculous metaphor about the number of way to skin a cat? Was that really a thing?)
LOL - and sixty seconds for a network timeout is an eternity! :) Except on dial-up and some old forms of single channel DSL! Or... "Hang on, maw! I'm adjusting the satellite dish!"
Rich:
Hi CentralWare
--- Quote from: CentralWare on August 16, 2024, 02:59:45 AM --- ... LOL - and sixty seconds for a network timeout is an eternity! :) Except on dial-up and some old forms of single channel DSL! Or... "Hang on, maw! I'm adjusting the satellite dish!"
--- End quote ---
If you look at settime.sh in isolation, that might be true.
Examined in context, 60 seconds might not be such a bad choice.
Looking in tc-config we find this:
--- Code: --- [ -z "$DHCP_RAN" ] && /etc/init.d/dhcp.sh &
[ -z "$NORTC" ] || /etc/init.d/settime.sh &
--- End code ---
Both dhcp and settime are launched into the background at the
same time. So right off the bat we are waiting for dhcp to finish.
dhcp starts with this:
--- Code: ---/sbin/udevadm settle --timeout=5
--- End code ---
So it could wait for up to 5 seconds for udev.
Then, for each interface it finds, it executes this:
--- Code: --- /sbin/udhcpc -b -i $DEVICE -x hostname:$(/bin/hostname) -p /var/run/udhcpc.$DEVICE.pid >/dev/null 2>&1 &
--- End code ---
This command has been backgrounded. That may speed things up
since DHCP requests for multiple device will be sent out back to back.
Not being familiar with udhcpc , I ask for some help. The following
options stood out to me, since they were not specified in the
original command:
--- Code: ---tc@E310:~$ udhcpc --help
BusyBox v1.29.3 (2018-12-19 15:29:37 UTC) multi-call binary.
----- Snip -----
-t N Send up to N discover packets (default 3)
-T SEC Pause between packets (default 3)
-A SEC Wait if lease is not obtained (default 20)
----- Snip -----
--- End code ---
If I am reading that correctly, in the worst case this would happen:
--- Code: ---Time Action
00 Send DHCP request
20 Wait 20 Secs for response
23 Pause for 3 Seconds
23 Send DHCP request
43 Wait 20 Secs for response
46 Pause for 3 Seconds
46 Send DHCP request
66 Wait 20 Secs for response
--- End code ---
And if udev takes the full 5 Secs that's 71 Secs.
To me, this looks like hoping for the best (usual outcome), and
trying to plan for the worst (corner cases).
Since the timeout terminates once the interface is detected, faster
systems won't be impacted by a 60 Sec timeout.
Paul_123:
The udhcpc that is built into busybox seems to struggle with some dhcp servers. Most users get an address after the first or second dhcp request, but I have users that report much longer, specifically on newer routers and primarily on the wifi side.
Run ntpd in daemon mode if you really want to be sure time stays set properly.
CentralWare:
--- Quote from: Rich on August 16, 2024, 11:24:14 AM ---
--- Code: ---[ -z "$DHCP_RAN" ] && /etc/init.d/dhcp.sh &
[ -z "$NORTC" ] || /etc/init.d/settime.sh &
--- End code ---
--- End quote ---
This is just personal preference/taste, but IIWM my mind sees this as more efficient if it were dhcp.sh && settime.sh (in series) as the hardware we're physically running on isn't determined and tc-config is virtually identical with all platforms, but all of the platforms are "not created equal" so to speak. This is why we (on my end) have a dedicated networking script; to separate hardware based on platforms and to try and compensate for quirks that come with each. Again, this is mere preference.
$NORTC only works if your RTC chip and its crystal are perfectly tuned... the radio in my truck is almost +1min ahead every month, the clock above my fridge behind me is a good deal more than 1min behind per month - but it's a cheap clock! :) RTC circuits are only as good as the crystal that makes them "tick." That said, even RTC has to be updated from time to time. The clock above this monitor... -3 minutes since 01-01-24... it's actually the closest non-netwoked clock here and it's only here because it's adhered to the bookshelf!! HOWEVER, RTC works great for giving the system hardware clock a head start before we've had a chance to sync with an atomic clock somewhere.
--- Quote from: Paul_123 on August 16, 2024, 11:52:14 AM ---The udhcpc that is built into busybox seems to struggle with some dhcp servers. Most users get an address after the first or second dhcp request, but I have users that report much longer, specifically on newer routers and primarily on the wifi side.
--- End quote ---
I have found that dnsmasq (and in turn, WRT and similar projects) tends to be on the list of DHCP servers which busybox's udhcpc hiccups on. Looking at logs, I cannot "see" what the issue is, but I get responses from dnsmasq 3, 4 or even 5 times and udhcpc doesn't seem to even "see" them, let alone accept the content, until numerous attempts have blown through then randomly... "OH! Hello! Thanks for getting back to me!" That said, I couldn't tell if it were udev not completely settled for ipv4 devices, BB's DHCP client, DNSmasq itself or something entirely out of the Twilight Zone... finally I just said "screw it, we'll work around it." If memory serves, I may have even posted things on the forum here back when RasPi-2 was young on this specific topic.
Navigation
[0] Message Index
[*] Previous page
Go to full version