ipFire behind LIWEST cable modem in bridging mode - getting no RED ip

cfusco · 23 August 2023 16:16

Question, is my interpretation of the chain of events correct?

At the end of the boot process, rc.local will be executed as the last script to run. Then, the inner parentheses will create a sub-shell, where there will be an instruction to wait for 10 min and then a restart of the network interfaces. The ampersand & puts this subshell in the background and forks again, further distancing from the initial process. This “double-forking” ensures that the process will continue to run even when the terminal or shell that launched it is closed because the process, if orphaned, will be adopted by PID 1 (init process).

holger · 23 August 2023 18:53

Hi @cfusco

I’m far, far away of being an expert of IPFire. I installed IPFire about 3 hours ago for the first time (in some virtual machine) to take a closer look at it. Nor I’m an expert of the Linux OS - I have just gained some experience with it while using it for… a longer period of time

…as far as I know:

yes - normal boot (to a command line interface) enters runlevel 3. All scripts in /etc/rc.d/rc3.d will be processed in alphabetical order and the last entry in this directory “S98rc.local” is a link to this rc.local script

…and yes - this was the idea behind but it does not work the way it was supposed to It still works but if the parent process gets a kill signal, the child process completes the sleep command but gets killed right after the sleep finishes and the rest is skipped But since there is no watchdog mechanism to kill the parent process it still works. The rc.d scripts are called with the sh interpreter and not with bash - maybe that’s the problem…

arne_f · 24 August 2023 08:01

I have not mentioned PPPoE. Some ISP’s use Dual-Stack lite or Carrier Grade Nat.

In this case you get a private IP address from your ISP. This may also assigned via DHCP.

arne_f · 24 August 2023 08:04

Try “connscheduler reconnect” instead of networking restart to restart only red.

cfusco · 24 August 2023 08:05

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?

( trap '' HUP; sleep 600; /etc/init.d/networking restart ) &

but this should not prevent other signal to propagate.

EDIT: maybe disown will detach the process from the calling shell:

(( sleep 600 ; /etc/init.d/networking restart ) & disown )

This incorporates Arne suggestion:

(( sleep 600 ; connsheduler reconnect ) & disown )

dnl · 24 August 2023 10:31

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.

bbitsch · 24 August 2023 18:48

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.

dnl · 24 August 2023 23:40

Is there any way the RED interface can be restarted alone please?

Sadly connscheduler reconnect is unreliable for me. It worked less than 1/4 of the times I tried.

I’d rather not have to stop all network interfaces (GREEN/BLUE/RED) so I’m trying to find a way to restart RED only.

Thanks!

cfusco · 25 August 2023 11:25

should be:
/etc/rc.d/init.d/networking/red stop

followed by:
/etc/rc.d/init.d/networking/red start

dnl · 25 August 2023 11:36

EDIT: Thanks @cfusco I’ll give that a try.

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.

cfusco · 25 August 2023 11:42

this is the relevant part of the network script:

case "${DO}" in
        start)
                # Starting interfaces...
                # GREEN
                [ "$green" == "1" ] && /etc/rc.d/init.d/networking/green start

                # BLUE
                [ "$blue" == "1" ] && [ "$CONFIG_TYPE" = "3" -o "$CONFIG_TYPE" = "4" ] && \
                        /etc/rc.d/init.d/networking/blue start

                # ORANGE
                [ "$orange" == "1" ] && [ "$CONFIG_TYPE" = "2" -o "$CONFIG_TYPE" = "4" ] && \
                        /etc/rc.d/init.d/networking/orange start

                # RED
                if [ "$red" == "1" ]; then
                        if [ "$CONFIG_TYPE" = "1" -o "$CONFIG_TYPE" = "2" -o "$CONFIG_TYPE" = "3" -o "$CONFIG_TYPE" = "4" ]; then
                                # Remove possible leftover files
                                rm -f /var/ipfire/red/{active,device,dial-on-demand,dns1,dns2,local-ipaddress,remote-ipaddress,resolv.conf}
                                [ "$AUTOCONNECT" == "off" ] || /etc/rc.d/init.d/networking/red start
                        fi
                fi

                # Create IPsec interfaces
                /usr/local/bin/ipsec-interfaces

                /etc/rc.d/init.d/static-routes start

                boot_mesg "Mounting network file systems..."
                mount -a -O _netdev
                evaluate_retval
                ;;

maybe it’s deleting those files?

cfusco · 25 August 2023 12:16

should be /etc/rc.d/init.d/networking/red stop

guebert · 29 August 2023 21:11

So as we see in this thread, there is need for a solution. Any chance to have it implemented in ipfire (as switchable option)?

How can we call the developers’ attention to this issue?

jon · 30 August 2023 00:12

To me it seems like a timed option is needed:

turn on gateway
wait - this may be one minute or ten minutes
turn on IPFire box
wait - this may be one minute to two minutes
turn on switches/hubs
wait - probably less than one minute
turn on wifi access points

Done!

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”.

EDIT: Pro Switch – Digital Loggers Direct

guebert · 30 August 2023 04:08

And how to handle unplanned reboots of the cable modem only (eg when the ISP does a configuration change)?

Why should people have to by hardware, when there is a (already available - script above) software solution?

Michael

guebert · 30 August 2023 04:22

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.

dnl · 30 August 2023 04:52

Sorry, I mean that you should create a symlink in the appropriate Cron directory.

ln -s /usr/local/bin/pingcheck.sh /etc/fcron.minutely/pingchech.sh

I’m typing this on a mobile so sorry if there are errors. When I get home I’ll update my original post

guebert · 30 August 2023 11:37

Many thanks!

Maybe you can post the script-file as well, please?

Did you test, if “red stop” / “red start” works instead of restarting all networks?

@Dev-Team: Any objection to implement this script and execution in the next build? PLEASE

cfusco · 30 August 2023 12:36

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.

guebert · 30 August 2023 16:16

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?)

Michael