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

Thanks for the comments guys.

@guebert please read all lines starting with a comment # inline.

# 1. Open an SSH session to IPFire as root
# 2. Paste this entire block of text.  It will
#     * Create the script below at /usr/local/bin/pingcheck.sh
#     * Ensure the permissions of the script are correct
#     * Create a symlink in the /etc/fcron.minutely directory so that the script is run each minute
cat <<EOF > /usr/local/bin/pingcheck.sh
#!/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"

        # NOTE restarting the network is a "last resort", you should first try:
		#/usr/local/bin/connscheduler reconnect > /dev/null
        # Then if that doesn't work try:
        #/etc/rc.d/init.d/networking/red stop
        #/etc/rc.d/init.d/networking/red start
        # Before falling back to the network stop & start "big hammer" approach
		/etc/init.d/network stop
		/etc/init.d/network start
	fi
fi
EOF
chmod 0755 /usr/local/bin/pingcheck.sh
ln -s /usr/local/bin/pingcheck.sh /etc/fcron.minutely/pingchech.sh
# The script will now run every minute.  You can edit it to try different reconnection options using your favourite editor (if you're new, nano or pico is available as an IPFire extensio - see the Pakfire menu).
# When testing different connection options, you may also want to increase the value of PING_TIMEOUT at the start of the script from 5 to 10.
# End

Sorry for the quick inline comments, I’m not at home at the moment.
This uses a bash “heredoc” to input a file (the script), sets the permissions for it then creates the symlink in to the /etc/fcron.minutely directory. Fcron automatically takes care of the rest.

Hope it helps!

When I have time at home next and no one is using the internet I’ll re-test different connection options again. For the moment only a full network restart has proven reliable for me.

1 Like

Many thanks!!!

Michael

@guebert, have you solved your problem / found the error in your connection?
The pingcheck script hides the problem only. dhcpcd should get its IP without, just using the DHCP protocol!

EDIT: Just saw in another post a possible solution.
Have you disabled rapid-commit in dhchcd.conf? Some ISPs seem to have problems with that option, which is well-defined in the RFCs. They refuse to hand out IPs, if this option is set.

2 Likes

Could you please post a link?

The pingcheck script hides the problem only. dhcpcd should get its IP without, just using the DHCP protocol!

No, it does not “hide” it, but provide a working solution. “Should” does not help - it does not work without.

I implemented the script but did not run many tests till now.

Michael

The link is No inbound traffic on DHCP RED - #13 by bonnietwin .

The script hides the problem, because it tries to circumvents ISP’s DHCP server error. IMO

You previously mentioned Cable Modems, but I have a VDSL modem.
I’ve not had time to try packet capture but from what I’m told ISP uses Cisco gear.

According to the thread opener we talk about cable modems ( DOCSIS ).
Don’t know, whether similiar problems arise with VDSL(DHCP).

Well I’m using VDSL and it’s happening for me.

If I spend the time to do a packet capture could you please suggest what I should be looking for?

Thank you

FYI, I set timeout to 180 and now the result is this:

|13:01:37|dhcpcd[1828]|: red0: adding default route via 212.241.107.1|
|---|---|---|
|13:01:37|dhcpcd[1828]|: red0: adding route to 212.241.107.0/24|
|13:01:37|dhcpcd[1828]|: red0: leased 212.241.107.75 for 604800 seconds|
|13:01:32|dhcpcd[1828]|: red0: probing address 212.241.107.75/24|
|13:01:32|dhcpcd[1828]|: red0: offered 212.241.107.75 from 212.33.36.130|
|13:01:04|dhcpcd[1828]|: red0: soliciting a DHCP lease|
|13:01:02|dhcpcd[1828]|: red0: deleting route to 192.168.100.0/24|
|13:01:02|dhcpcd[1828]|: red0: DHCP lease expired|
|13:01:00|dhcpcd[1828]|: red0: failed to renew DHCP, rebinding|
|13:00:42|dhcpcd[1828]|: red0: adding route to 192.168.100.0/24|
|13:00:42|dhcpcd[1828]|: red0: leased 192.168.100.20 for 20 seconds|
|13:00:37|dhcpcd[1828]|: red0: probing address 192.168.100.20/24|
|13:00:37|dhcpcd[1828]|: red0: offered 192.168.100.20 from 192.168.100.1|
|13:00:07|dhcpcd[1828]|: red0: soliciting a DHCP lease|
|13:00:06|dhcpcd[1828]|: red0: IAID b9:5a:bf:80|
|13:00:06|dhcpcd[1828]|: red0: carrier acquired|
|13:00:03|dhcpcd[1828]|: red0: carrier lost|
|12:59:41|dhcpcd[1828]|: red0: soliciting a DHCP lease|
|12:59:41|dhcpcd[1828]|: red0: IAID b9:5a:bf:80|
|12:59:41|dhcpcd[1828]|: red0: carrier acquired|
|12:59:38|dhcpcd[1828]|: red0: waiting for carrier|
|12:59:38|dhcpcd[1828]|: DUID 00:01:00:01:2a:42:67:45:00:0d:b9:5a:bf:80|
|12:59:38|dhcpcd[1825]|: dhcpcd-10.0.1 starting|

So it takes from 12:59:38 till 13:01:32 (= 114 sec) till my ISP cable modem offers the real external IP! As you can see from my initial post, the default timeout of ipfire was 60 sec which is much too low. So I suggest to set this parameter to a higher value by default.

BTW I also implemented the script of “dnl” (ipFire behind LIWEST cable modem in bridging mode - getting no RED ip - #22 by dnl) just for safety. I changed the first parameter to wait after reboot to 180, too.