[Bug] Flint 2 - Op 24 4.8.3 pppoe delay bug

I have an internet provider that resets the public IP every 12 hours, so my wan connection gets reset.

With my previous router, this action wasn’t noticeable to me, but now, with Flint 2 MT6000 I realized a certain delay. After looking at the logs, I saw a consistent 30s delay.

After digging a bit, I found this script: /lib/netifd/proto/ppp.sh which looks like it’s triggered on wan reconnections.

Looks like it’s a modified version of the official openwrt: openwrt/package/network/services/ppp/files/ppp.sh at openwrt-24.10 · openwrt/openwrt · GitHub

The bug:

There is a add_fail_count method that’s triggered on every reconnection

add_fail_count() {
	local count=0
	[ -f $FAIL_COUNT ] && {
		count=$(cat $FAIL_COUNT)
	}

	let count=count+1
	echo $count > $FAIL_COUNT
}

Stored in FAIL_COUNT=/tmp/pppoe_fail_count, but it should reset after a successful connection. (removing the file could be enough).

The following method adds the delay if fails are gt 3

delay_dail() {
	local count=0
	[ -f $FAIL_COUNT ] && {
		count=$(cat $FAIL_COUNT)
	}

	[ $count -gt 3 ] && {
		sleep 30
	}
}

First of all, I want to ask if this custom code was added by the GL iNet team. If so, can it be removed?

1 Like

Hello,

This script was own developed and added by gl.

Yep, you can temporarily remove this script if this causes issue.

The issue you encountered is that after 3 failures (times), did pppoe take too long to reconnect?

Thanks for reaching out.

Yes, I’ve commented out the custom delay_dail call as a workaround.

The issue is that the error counter is increasing every 12 hours (due to my ISP resetting the connection to refresh the public IP), so after a few days I’ll always face that GL iNet added 30 seconds delay on connection reset.

If it’s during a meeting or online game, it’s noticeable.

  1. I don’t think it’s needed
  2. If needed, I’d recommend resetting the FAIL_COUNT after a successful connection. (Currently it’s only reset after a router reboot I guess, because it’s stored under /tmp)
  3. Adding an option to disable it could be nice too.

I think we might need to optimize this script.
Let me submit it to the R&D guys for further evaluation.

1 Like

Thanks Bruce!

I will stay tuned for the resolution.