this means that the kill signal is also sent to the child process. Since sleep is a blocking command the child process should continue sleeping for the specified duration. Once the sleep command completes, the child process will check for pending signals. If a kill signal is pending, the child process will be terminated before it has a chance to execute the next command. Maybe a TRAP can prevent the kill signal to propagate to the child process?
Hello,
I was notified of this thread because someone linked to the thread I raised years ago. I still have the problem that I reported there, so I worked around it with the following script.
This is saved as /usr/local/bin/pingcheck.sh and linked in to the /etc/fcron.minutely/ directory.
#!/bin/bash
#
########################################################################
# Begin
#
# Description : Gateway ping check
#
# Authors : DNL
#
# Version : 01.20
#
# Notes : Designed to run regularly from cron. Restarts red0
# network if unable to ping ISP's router.
#
########################################################################
PING_TIMEOUT=5
MAX_RETRIES=4
ATTEMPT=0
# Don't run in the first 120 seconds after IPFire has booted
if [[ $( cut -d'.' -f1 /proc/uptime ) -gt 120 ]]; then
RED_TYPE=$(grep RED_TYPE /var/ipfire/ethernet/settings | cut -d'=' -f2)
REMOTE_IP=$(cat /var/ipfire/red/remote-ipaddress)
if [[ "$RED_TYPE" == "DHCP" ]]; then
while [[ $ATTEMPT -le $MAX_RETRIES ]]; do
if ping -q -c 1 -w $PING_TIMEOUT "${REMOTE_IP}" &>/dev/null
then
# Connection is up - exit quietly
exit 0
else
ATTEMPT=$(( ATTEMPT+1 ))
sleep $PING_TIMEOUT
fi
done
logger -p local0.info -t pingcheck.sh[$$] "Unable to ping upstream router. Restarting RED connection"
# try `connscheduler reconnect` first instead of restarting the network. - sadly it does not work for me.
#/usr/local/bin/connscheduler reconnect > /dev/null
/etc/init.d/network stop
# DEBUG logger -p local0.info -t pingcheck.sh[$$] "Stopping red connection returned $?"
# DEBUG logger -p local0.info -t pingcheck.sh[$$] "Starting red connection"
/etc/init.d/network start
fi
fi
This cron job has run on my system since that thread years ago and has proven to be reliable. EDIT: @arne_f 's tip of running connsheduler reconnect sadly does not work at all for me, so I have resorted back to a full network stop/start. Perhaps the problem I have is related to what the connscheduler script does?
Thanks for the tip about modifying the timeout in /var/ipfire/dhcpc/dhcpcd.conf@bonnietwin . EDIT: I tried it just now at 120 and it still failed to work. Two minutes seems like a very long time, but given that connscheduler reconnect fails for me perhaps I have another issue.
It is true, that ISPs tend to go their own way on supplying DOCSIS based internet.
The basic idea of IP assignment of a DOCSIS modem ( CPE ) is
while the connection to the CMTS isn’t up, the modem works as a DHCP server in the 192.168.100.0/24 network ( lease time short, 30s for example )
when the connection is established, the DHCP server stops. DHCP requests are forwarded to the ISP DHCP server.
renewing the private IP with short lease time, results in the detection of the internet connection by a RENEW/NAK/DISCOVER/OFFER sequence resulting in a public IP.
dhcpcd handles this procedure right.
Problem is that some DHCP servers of ISPs do not implement the simple algorithm explained above.
ISPs further tend to not providing a simple modem ( or a router with bridge mode ), but router with its behaviour of its own ( defined by ISP ). A router should handle the process much easier ( supply a private address, which doesn’t change independent of the online status of the WAN side ).
Obviously there are problems on the ISP side, which should be solved on the side. There is no save procedure in IPFire to circumvent these problems. My opinion.
I went through backups and I had previously tried /etc/init.d/network stop red and /etc/init.d/network start red, however it wasn’t as reliable as restarting all networking.
When I’m able I’ll try that and see if there’s any difference in the shell scripts.
So in my opinion people are using the wrong tool for the job by making ipfire do the work…
I would suggest buying something like this:
It has programable outlets (if I picked the right one!) where it does the above list. There are others but this is the one I could find quickly. FYI don’t search for just “watchdog”. You will get LOTS of entries for “basement water watchdog”.
Can you explain how to do this to a non-ipfire expert, please? I can work with putty, but I’m not familiar with Linux and have to google every command.
I’m not speaking on behalf of the development team, but based on my understanding, it’s unlikely that this script will be integrated into the standard release. The script serves specific needs and isn’t universally applicable. Adding it as a checkbox in the Web User Interface would entail discussions, coding, and rigorous testing—resources that could be spent on more pressing issues. For now, your best option is to adapt the script for your own setup and include it in your backups. If you need further guidance, feel free to ask.
It seems, that it’s a widely present problem with cable modems. Maybe lots of users even do not know, why ipfire does not connect after a reboot of the cable modem (and ipfire [at the same time]).
I’m not an expert, too, but maybe the DevTeam can have a look at this issue at all. (BTW, how about other systems like pfsense in this situations? Do they all have this problem? If not, why? Shouldn’t ipfire provide as much support to the user as needed to have a stable connection?)
as Arne mentioned in post 12, there’s no straightforward solution to this corner case. The script by @dnl is not a solution but a (useful and well written) workaround, pinging the gateway every 2 minutes.
This issue mainly arises from a subset of providers deviating from industry standards, as outlined by @bonnietwin in post 23. Given these complexities, there is limited incentive for the development team to take action at the expenses of other pressing issues.
However, I’m happy to help you implement the script and set up backups to maintain its functionality over time. We could also condense this thread into a how-to guide to assist future IPFire users facing similar issues.
I agree with @cfusco.
I had this problem some time also. Without great modifications to the IPFire code ( dhcpcd especially ), the issue has gone. Either my provider is conforming more the standard now, or dhcpcd is now mofe able to circumvent these errors ( the producer of the modem or CMTS SW may it call features ).
To investigate you should record the packet traffic concerning the DHCP protocol with tcpdump.
With this capture(s) one can either find problems on IPFire’s ( dhcpcd ) side or the providers part.
Especially for a restart of the modem dhcpcd should handle this without problem. As far as I know the defined timeouts should be sufficient.
Offline times longer as these timeouts show problems on the DOCSIS ( Cable Internet ) side and should be handled on the provider side.
( IPFire can’t remedy all hickups because of the incompleteness of DWIM, which isn’t even implemented in IPFire )
within the /etc/hosts file is gateway so if you ping gateway you will get the same as ping "${REMOTE_IP}"
NOTE: I have not tested this in your script and I do not know when gateway or the file /var/ipfire/red/remote-ipaddress is set during a reboot or power-up
Hey @jon I don’t remember why I went with that, I think I was trying to use where IPFire stores the IP of the upstream gateway. It’s also possible that /etc/hosts may not have all entries in it when your connection is down. I’m not at home now to check.
warning - wild tangent below