PPPoE WAN stability issues with BT

spencer99

Hi,

Been having some issues lately with network stability.

Im in the UK running a Vigor 130 Modem on a BT Business connection.

My old pfSense box started dropping connection for long periods of time requiring a restart to remedy the issue, I could not access the webgui during these drop outs. I thought it could have been a symptom of a hardware failure, maybe a dead memory stick or NIC so swapped out all of my H/W for fresh stuff which I had from a previous build which I knew worked. Did a fresh install of pfSense 2.6 and then imported my old config. The issue still persisted so I checked the modem, I swapped the Vigor out for a spare BT Openreach modem I have, still the same issue. At this point I was seeing a reduced sync speed on the Vigor as well, and the drop outs were becoming more regular but shorter, when the WAN connection was on it was provided unreliable speeds too, ranging from 1mbps to 55mbps. One thing I also noticed was that after most drop outs I could no longer access the webgui until I restarted php-fpm using either SSH or directly on the router.

We had an engineer come out from BT as I thought it was an issue with the line between the house and the cabinet, this turned out to be partially true, as there was an issue with some of the DSL ports scattered around the house, as a result he disconnected all but 1 of the additional DSL ports in the house. This initially seemed to remedy the issue for around 4 days we had a solid connection with no dropouts testing consistently at 70+mbps.

Then today comes around and the issue has returned, regular drop outs with sketchy speeds. The sync speed on the Vigor is still reading correctly this time though. This is leading me to believe that part of the issue may be config related but I am unsure what as I havent changed anything major recently.

Below are the logs immediately after the pfSense box has recovered from a drop out.

May 7 14:00:46	rc.gateway_alarm	22487	>>> Gateway alarm: WAN_PPPOE (Addr:1.1.1.1 Alarm:1 RTT:26.702ms RTTsd:16.778ms Loss:22%)
May 7 14:00:46	check_reload_status	33938	updating dyndns WAN_PPPOE
May 7 14:00:46	check_reload_status	33938	Restarting IPsec tunnels
May 7 14:00:46	check_reload_status	33938	Restarting OpenVPN tunnels/interfaces
May 7 14:00:46	check_reload_status	33938	Reloading filter
May 7 14:00:46	check_reload_status	33938	Linkup starting em1
May 7 14:00:46	kernel		em1: link state changed to DOWN
May 7 14:00:47	php-fpm	26538	/rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN_PPPOE.
May 7 14:00:47	php-fpm	65955	/rc.linkup: Hotplug event detected for MODEM(opt2) static IP (192.168.1.100 )
May 7 14:00:47	php-fpm	33391	/rc.dyndns.update: phpDynDNS (xxx.ddns.net): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
May 7 14:00:47	check_reload_status	33938	Reloading filter
May 7 14:00:48	php-fpm	4545	/rc.filter_configure_sync: [squid] Installed but disabled. Not installing 'nat' rules.
May 7 14:00:48	php-fpm	4545	/rc.filter_configure_sync: [squid] Installed but disabled. Not installing 'pfearly' rules.
May 7 14:00:48	php-fpm	4545	/rc.filter_configure_sync: [squid] Installed but disabled. Not installing 'filter' rules.
May 7 14:00:48	php-fpm	33391	/rc.dyndns.update: phpDynDNS (xxx.ddns.net): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
May 7 14:00:49	check_reload_status	33938	Linkup starting em1
May 7 14:00:49	kernel		em1: link state changed to UP
May 7 14:00:49	php-fpm	65955	/rc.filter_configure_sync: [squid] Installed but disabled. Not installing 'nat' rules.
May 7 14:00:49	php-fpm	65955	/rc.filter_configure_sync: [squid] Installed but disabled. Not installing 'pfearly' rules.
May 7 14:00:49	php-fpm	65955	/rc.filter_configure_sync: [squid] Installed but disabled. Not installing 'filter' rules.
May 7 14:00:49	php-fpm	33391	/rc.dyndns.update: phpDynDNS (xxx.ddns.net): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
May 7 14:00:50	php-fpm	2933	/rc.linkup: Hotplug event detected for MODEM(opt2) static IP (192.168.1.100 )
May 7 14:00:50	check_reload_status	33938	rc.newwanip starting em1
May 7 14:00:50	ppp	51379	Multi-link PPP daemon for FreeBSD
May 7 14:00:50	ppp	51379	process 51379 started, version 5.9
May 7 14:00:50	ppp	51379	waiting for process 18665 to die...
May 7 14:00:50	ppp	18665	caught fatal signal TERM
May 7 14:00:50	ppp	18665	[wan] IFACE: Close event
May 7 14:00:50	ppp	18665	[wan] IPCP: Close event
May 7 14:00:50	ppp	18665	[wan] IPCP: state change Opened --> Closing
May 7 14:00:50	ppp	18665	[wan] IPCP: SendTerminateReq #4
May 7 14:00:50	ppp	18665	[wan] IPCP: LayerDown
May 7 14:00:50	php-fpm	2933	/rc.linkup: calling interface_dhcpv6_configure.
May 7 14:00:50	php-fpm	2933	/rc.linkup: Accept router advertisements on interface em1
May 7 14:00:50	php-fpm	2933	/rc.linkup: Starting rtsold process
May 7 14:00:50	check_reload_status	33938	Rewriting resolv.conf
May 7 14:00:50	ppp	18665	[wan] IFACE: Removing IPv4 address from pppoe0 failed(IGNORING for now. This should be only for PPPoE friendly!): Can't assign requested address
May 7 14:00:50	ppp	18665	[wan] IPV6CP: Close event
May 7 14:00:50	ppp	18665	[wan] IPV6CP: state change Opened --> Closing
May 7 14:00:50	ppp	18665	[wan] IPV6CP: SendTerminateReq #2
May 7 14:00:50	ppp	18665	[wan] IPV6CP: LayerDown
May 7 14:00:50	check_reload_status	33938	Rewriting resolv.conf
May 7 14:00:50	ppp	18665	[wan] IFACE: Down event
May 7 14:00:50	ppp	18665	[wan] IFACE: Rename interface pppoe0 to pppoe0
May 7 14:00:50	ppp	18665	[wan] IFACE: Set description "WAN"
May 7 14:00:50	php-fpm	33391	/rc.dyndns.update: phpDynDNS (xxx.ddns.net): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
May 7 14:00:51	ppp	51379	waiting for process 18665 to die...
May 7 14:00:51	php-fpm	64430	/rc.newwanip: rc.newwanip: Info: starting on em1.
May 7 14:00:51	php-fpm	64430	/rc.newwanip: rc.newwanip: on (IP address: 192.168.1.100) (interface: MODEM[opt2]) (real interface: em1).
May 7 14:00:51	check_reload_status	33938	Reloading filter
May 7 14:00:51	php-fpm	33391	/rc.dyndns.update: phpDynDNS (xxx.ddns.net): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
May 7 14:00:52	ppp	51379	waiting for process 18665 to die...
May 7 14:00:52	php-fpm	4545	/rc.filter_configure_sync: [squid] Installed but disabled. Not installing 'nat' rules.
May 7 14:00:52	php-fpm	4545	/rc.filter_configure_sync: [squid] Installed but disabled. Not installing 'pfearly' rules.
May 7 14:00:52	check_reload_status	33938	Restarting IPsec tunnels
May 7 14:00:52	php-fpm	4545	/rc.filter_configure_sync: [squid] Installed but disabled. Not installing 'filter' rules.
May 7 14:00:52	ppp	18665	[wan] Bundle: Shutdown
May 7 14:00:52	ppp	18665	[wan_link0] Link: Shutdown
May 7 14:00:52	ppp	18665	process 18665 terminated
May 7 14:00:52	rtsold	52641	<rtsock_input_ifannounce> interface pppoe0 removed
May 7 14:00:52	rtsold	66941	Received RA specifying route fe80::21d:aaff:fe8d:d624 for interface wan(em1)
May 7 14:00:52	rtsold	67276	RTSOLD Lock in place - sending SIGHUP to dhcp6c
May 7 14:00:52	php-fpm	33391	/rc.dyndns.update: Dynamic DNS noip (xxx.ddns.net): IP address could not be extracted from Check IP Service
May 7 14:00:52	php-fpm	33391	/rc.dyndns.update: Dynamic DNS (xxx.ddns.net) There was an error trying to determine the public IP for interface - wan (pppoe0 ).
May 7 14:00:53	ppp	51379	web: web is not running
May 7 14:00:53	ppp	51379	[wan] Bundle: Interface ng0 created
May 7 14:00:53	ppp	51379	[wan_link0] Link: OPEN event
May 7 14:00:53	kernel		ng0: changing name to 'pppoe0'
May 7 14:00:53	ppp	51379	[wan_link0] LCP: Open event
May 7 14:00:53	ppp	51379	[wan_link0] LCP: state change Initial --> Starting
May 7 14:00:53	ppp	51379	[wan_link0] LCP: LayerStart
May 7 14:00:53	ppp	51379	[wan_link0] PPPoE: Connecting to ''
May 7 14:01:00	php	34666	servicewatchdog_cron.php: Service Watchdog detected service openvpn stopped. Restarting openvpn (OpenVPN server: AlphaOVPN-HCMPRS)
May 7 14:01:02	ppp	51379	[wan_link0] PPPoE connection timeout after 9 seconds
May 7 14:01:02	ppp	51379	[wan_link0] Link: DOWN event
May 7 14:01:02	ppp	51379	[wan_link0] LCP: Down event
May 7 14:01:02	ppp	51379	[wan_link0] Link: reconnection attempt 1 in 2 seconds
May 7 14:01:04	ppp	51379	[wan_link0] Link: reconnection attempt 1
May 7 14:01:04	ppp	51379	[wan_link0] PPPoE: Connecting to ''
May 7 14:01:13	ppp	51379	[wan_link0] PPPoE connection timeout after 9 seconds
May 7 14:01:13	ppp	51379	[wan_link0] Link: DOWN event
May 7 14:01:13	ppp	51379	[wan_link0] LCP: Down event
May 7 14:01:13	ppp	51379	[wan_link0] Link: reconnection attempt 2 in 2 seconds
May 7 14:01:15	ppp	51379	[wan_link0] Link: reconnection attempt 2
May 7 14:01:15	ppp	51379	[wan_link0] PPPoE: Connecting to ''
May 7 14:01:24	ppp	51379	[wan_link0] PPPoE connection timeout after 9 seconds
May 7 14:01:24	ppp	51379	[wan_link0] Link: DOWN event
May 7 14:01:24	ppp	51379	[wan_link0] LCP: Down event
May 7 14:01:24	ppp	51379	[wan_link0] Link: reconnection attempt 3 in 3 seconds
May 7 14:01:27	ppp	51379	[wan_link0] Link: reconnection attempt 3
May 7 14:01:27	ppp	51379	[wan_link0] PPPoE: Connecting to ''
May 7 14:01:36	ppp	51379	[wan_link0] PPPoE connection timeout after 9 seconds
May 7 14:01:36	ppp	51379	[wan_link0] Link: DOWN event
May 7 14:01:36	ppp	51379	[wan_link0] LCP: Down event
May 7 14:01:36	ppp	51379	[wan_link0] Link: reconnection attempt 4 in 4 seconds
May 7 14:01:40	ppp	51379	[wan_link0] Link: reconnection attempt 4
May 7 14:01:40	ppp	51379	[wan_link0] PPPoE: Connecting to ''
May 7 14:01:42	ppp	51379	PPPoE: rec'd ACNAME "acc-aln2.tep"
May 7 14:01:42	ppp	51379	[wan_link0] PPPoE: connection successful
May 7 14:01:42	ppp	51379	[wan_link0] Link: UP event
May 7 14:01:42	ppp	51379	[wan_link0] LCP: Up event
May 7 14:01:42	ppp	51379	[wan_link0] LCP: state change Starting --> Req-Sent
May 7 14:01:42	ppp	51379	[wan_link0] LCP: SendConfigReq #1
May 7 14:01:42	ppp	51379	[wan_link0] PROTOCOMP
May 7 14:01:42	ppp	51379	[wan_link0] MRU 1492
May 7 14:01:42	ppp	51379	[wan_link0] MAGICNUM 0x559bdbd5
May 7 14:01:42	ppp	51379	[wan_link0] LCP: rec'd Configure Request #0 (Req-Sent)
May 7 14:01:42	ppp	51379	[wan_link0] MRU 1492
May 7 14:01:42	ppp	51379	[wan_link0] AUTHPROTO CHAP MD5
May 7 14:01:42	ppp	51379	[wan_link0] MAGICNUM 0x67491f38
May 7 14:01:42	ppp	51379	[wan_link0] LCP: SendConfigAck #0
May 7 14:01:42	ppp	51379	[wan_link0] MRU 1492
May 7 14:01:42	ppp	51379	[wan_link0] AUTHPROTO CHAP MD5
May 7 14:01:42	ppp	51379	[wan_link0] MAGICNUM 0x67491f38
May 7 14:01:42	ppp	51379	[wan_link0] LCP: state change Req-Sent --> Ack-Sent
May 7 14:01:42	ppp	51379	[wan_link0] LCP: rec'd Configure Reject #1 (Ack-Sent)
May 7 14:01:42	ppp	51379	[wan_link0] PROTOCOMP
May 7 14:01:42	ppp	51379	[wan_link0] LCP: SendConfigReq #2
May 7 14:01:42	ppp	51379	[wan_link0] MRU 1492
May 7 14:01:42	ppp	51379	[wan_link0] MAGICNUM 0x559bdbd5
May 7 14:01:42	ppp	51379	[wan_link0] LCP: rec'd Configure Ack #2 (Ack-Sent)
May 7 14:01:42	ppp	51379	[wan_link0] MRU 1492
May 7 14:01:42	ppp	51379	[wan_link0] MAGICNUM 0x559bdbd5
May 7 14:01:42	ppp	51379	[wan_link0] LCP: state change Ack-Sent --> Opened
May 7 14:01:42	ppp	51379	[wan_link0] LCP: auth: peer wants CHAP, I want nothing
May 7 14:01:42	ppp	51379	[wan_link0] LCP: LayerUp
May 7 14:01:42	ppp	51379	[wan_link0] CHAP: rec'd CHALLENGE #1 len: 68
May 7 14:01:42	ppp	51379	[wan_link0] Name: "acc-aln2.tep"
May 7 14:01:42	ppp	51379	[wan_link0] CHAP: Using authname "xxx@btinternet.com"
May 7 14:01:42	ppp	51379	[wan_link0] CHAP: sending RESPONSE #1 len: 51
May 7 14:01:42	ppp	51379	[wan_link0] CHAP: rec'd SUCCESS #1 len: 31
May 7 14:01:42	ppp	51379	[wan_link0] MESG: CHAP authentication success
May 7 14:01:42	ppp	51379	[wan_link0] LCP: authorization successful
May 7 14:01:42	ppp	51379	[wan_link0] Link: Matched action 'bundle "wan" ""'
May 7 14:01:42	ppp	51379	[wan_link0] Link: Join bundle "wan"
May 7 14:01:42	ppp	51379	[wan] Bundle: Status update: up 1 link, total bandwidth 64000 bps
May 7 14:01:42	ppp	51379	[wan] IPCP: Open event
May 7 14:01:42	ppp	51379	[wan] IPCP: state change Initial --> Starting
May 7 14:01:42	ppp	51379	[wan] IPCP: LayerStart
May 7 14:01:42	ppp	51379	[wan] IPV6CP: Open event
May 7 14:01:42	ppp	51379	[wan] IPV6CP: state change Initial --> Starting
May 7 14:01:42	ppp	51379	[wan] IPV6CP: LayerStart
May 7 14:01:42	ppp	51379	[wan] IPCP: Up event
May 7 14:01:42	ppp	51379	[wan] IPCP: state change Starting --> Req-Sent
May 7 14:01:42	ppp	51379	[wan] IPCP: SendConfigReq #1
May 7 14:01:42	ppp	51379	[wan] IPADDR 0.0.0.0
May 7 14:01:42	ppp	51379	[wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
May 7 14:01:42	ppp	51379	[wan] IPV6CP: Up event
May 7 14:01:42	ppp	51379	[wan] IPV6CP: state change Starting --> Req-Sent
May 7 14:01:42	ppp	51379	[wan] IPV6CP: SendConfigReq #1
May 7 14:01:42	ppp	51379	[wan] IPV6CP: rec'd Configure Request #216 (Req-Sent)
May 7 14:01:42	ppp	51379	[wan] IPV6CP: SendConfigAck #216
May 7 14:01:42	ppp	51379	[wan] IPV6CP: state change Req-Sent --> Ack-Sent
May 7 14:01:42	ppp	51379	[wan] IPCP: rec'd Configure Request #42 (Req-Sent)
May 7 14:01:42	ppp	51379	[wan] IPADDR 172.16.15.212
May 7 14:01:42	ppp	51379	[wan] 172.16.15.212 is OK
May 7 14:01:42	ppp	51379	[wan] IPCP: SendConfigAck #42
May 7 14:01:42	ppp	51379	[wan] IPADDR 172.16.15.212
May 7 14:01:42	ppp	51379	[wan] IPCP: state change Req-Sent --> Ack-Sent
May 7 14:01:42	ppp	51379	[wan] IPCP: rec'd Configure Reject #1 (Ack-Sent)
May 7 14:01:42	ppp	51379	[wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
May 7 14:01:42	ppp	51379	[wan] IPCP: SendConfigReq #2
May 7 14:01:42	ppp	51379	[wan] IPADDR 0.0.0.0
May 7 14:01:42	ppp	51379	[wan] IPV6CP: rec'd Configure Ack #1 (Ack-Sent)
May 7 14:01:42	ppp	51379	[wan] IPV6CP: state change Ack-Sent --> Opened
May 7 14:01:42	ppp	51379	[wan] IPV6CP: LayerUp
May 7 14:01:42	ppp	51379	[wan] 0215:17ff:fe7c:c298 -> a67b:2cff:fe50:a61f
May 7 14:01:42	check_reload_status	33938	rc.newwanipv6 starting pppoe0
May 7 14:01:42	ppp	51379	[wan] IFACE: Up event
May 7 14:01:42	ppp	51379	[wan] IFACE: Rename interface ng0 to pppoe0
May 7 14:01:42	ppp	51379	[wan] IFACE: Add description "WAN"
May 7 14:01:42	ppp	51379	[wan] IPCP: rec'd Configure Nak #2 (Ack-Sent)
May 7 14:01:42	ppp	51379	[wan] IPADDR 81.153.80.115
May 7 14:01:42	ppp	51379	[wan] 81.153.80.115 is OK
May 7 14:01:42	ppp	51379	[wan] IPCP: SendConfigReq #3
May 7 14:01:42	ppp	51379	[wan] IPADDR 81.153.80.115
May 7 14:01:42	ppp	51379	[wan] IPCP: rec'd Configure Ack #3 (Ack-Sent)
May 7 14:01:42	ppp	51379	[wan] IPADDR 81.153.80.115
May 7 14:01:42	ppp	51379	[wan] IPCP: state change Ack-Sent --> Opened
May 7 14:01:42	ppp	51379	[wan] IPCP: LayerUp
May 7 14:01:42	ppp	51379	[wan] 81.153.80.115 -> 172.16.15.212
May 7 14:01:42	check_reload_status	33938	rc.newwanip starting pppoe0
May 7 14:01:43	php-fpm	65955	/rc.newwanip: rc.newwanip: Info: starting on pppoe0.
May 7 14:01:43	php-fpm	80764	/rc.newwanipv6: rc.newwanipv6: Info: starting on pppoe0.
May 7 14:01:43	php-fpm	65955	/rc.newwanip: rc.newwanip: on (IP address: 81.153.80.115) (interface: WAN[wan]) (real interface: pppoe0).
May 7 14:01:43	php-fpm	80764	/rc.newwanipv6: rc.newwanipv6: No IPv6 address found for interface WAN [wan].
May 7 14:01:44	php-fpm	65955	/rc.newwanip: [squid] Installed but disabled. Not installing 'nat' rules.
May 7 14:01:44	php-fpm	65955	/rc.newwanip: [squid] Installed but disabled. Not installing 'pfearly' rules.
May 7 14:01:44	php-fpm	65955	/rc.newwanip: [squid] Installed but disabled. Not installing 'filter' rules.
May 7 14:01:44	php-fpm	65955	/rc.newwanip: Removing static route for monitor 1.1.1.1 and adding a new route through 172.16.15.212
May 7 14:01:44	php-fpm	65955	/rc.newwanip: Default gateway setting Interface WAN_PPPOE Gateway as default.
May 7 14:01:44	php-fpm	65955	/rc.newwanip: IP Address has changed, killing states on former IP Address 81.153.80.42.
May 7 14:01:47	check_reload_status	33938	updating dyndns wan
May 7 14:01:47	check_reload_status	33938	Reloading filter
May 7 14:01:49	php-fpm	33391	/rc.dyndns.update: Curl error occurred: Could not resolve host: dynupdate.no-ip.com
May 7 14:01:49	php-fpm	80764	/rc.filter_configure_sync: [squid] Installed but disabled. Not installing 'nat' rules.
May 7 14:01:49	php-fpm	80764	/rc.filter_configure_sync: [squid] Installed but disabled. Not installing 'pfearly' rules.
May 7 14:01:49	php-fpm	80764	/rc.filter_configure_sync: [squid] Installed but disabled. Not installing 'filter' rules.
May 7 14:01:53	php-fpm	65955	/rc.newwanip: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1651928513] unbound[64572:0] error: bind: address already in use [1651928513] unbound[64572:0] fatal error: could not open ports'
May 7 14:01:53	php-fpm	26538	/rc.dyndns.update: phpDynDNS: updating cache file /conf/dyndns_wannoip'xxx.ddns.net'0.cache: 81.153.80.115
May 7 14:01:53	php-fpm	26538	/rc.dyndns.update: phpDynDNS (xxx.ddns.net): (Success) IP Address Changed Successfully!
May 7 14:02:00	php	21471	servicewatchdog_cron.php: Service Watchdog detected service openvpn stopped. Restarting openvpn (OpenVPN server: AlphaOVPN-HCMPRS)

One thing I changed today was the gateway monitor IP as the BT one no longer worked, I have swapped to 1.1.1.1 and I noticed some odd packet loss spikes over the course of today which I have never seen before.

Anyone else had this issue/known what the issue might be?

Is it my config/equipment or have BT just not tested the line properly and there is still an issue.

Many thanks

stephenw10

BT's PPPoE gateways are often private IPs that don't respond to ping. Mine is here and yours look like that too in the log.

What sort of latency/packet loss are you seeing against 1.1.1.1?

If you only have one gateway you can disable gateway monitoring action to prevent unnecessary churn.

Steve

spencer99

@stephenw10

Its odd as I was able to use the default gateway monitor IP for a long time and it worked until a few months ago.

As for packet loss and latency, it varies wildly, for example right now I'm seeing 10ms with 0% packet loss but earlier today I has 20-30ms with 15% packet loss.

Reckon its possible that gateway monitoring has something to do with the issues?

To give an ideal of how wildly different things can get here is an image from my grafana speedtest DB from the last 2 days.

Spencer

stephenw10

Mmm, that doesn't look too bad. Some spikes like that when the line is saturated are to be expected.
But if you saw loss hit the 20% default threshold then the gateway would be marked down and the gateway action scripts fired. If you only have one gateway that only cause unnecessary disruption since there's no failover gateway.

My PPPoE gateway also responded fine to ping for years but stopped some time ago now.
You might try using 8.8.8.8 instead just to see if there's any difference.

Steve

spencer99

Just to add an update to this, the stability has become even worse now.

This is the last 7 days, im starting to see a pattern of downtime in the mornings, this graph doesnt show it very well. At around 6/7 in the morning the WAN will drop out and fail to recover until I manually restart the modem or reset the WAN interface on the pfSense box, I find it a little odd that it doesnt recover automatically.

I have also noticed my sync speed dropping consistently day in day.

f111a1aa-ff00-4346-a758-c57a898994b3-Screenshot 2022-05-13 100155.png

This is the VDSL Status from the Vigor 130, doesnt seem to have any errors but does seem to have a high SNR Margin, as far as I was aware that should be around 6dB? Those results are also directly from the test socket.

I also set the Vigor to use MPoA instead of PPPoA, that didnt help either.

stephenw10

I would also expect it to recover. Do you just see it continually trying to connect in the PPP logs? Any error shown or is it just not seeing any responses?

Steve

spencer99

@stephenw10 It seems to be attempting up to 20 times, then seeming like its about to success and then failing, excuse the massive logs but here is what I had from this morning for over an hour

https://pastebin.com/6cesuZyK

I would paste it inline but its 3500 log entries and thats after I filtered it lmao.

stephenw10

Ok I didn't read all of that but...

In fact it is reconnecting repeatedly and then disconnecting in a loop. It's not a PPP issue.

Did you disable gateway monitoring action? (assuming you only have one gateway).

Have you set 'State killing on gateway failure'?

Those things in combination could produce what you're seeing and neither is useful in a one WAN setup.

Steve

spencer99

@stephenw10
I have now disabled gateway monitor action and I have left state killing on gateway failure as default off.

I have also now disable the disabled the WAN_DHCP6 gateway as it was offline anyway.

So by the sounds of it my connection being unstable and triggering the gateway reset due to packet loss is also triggering another error state which gets stuck in a loop.

Spencer

stephenw10

Yeah, that's what the logs look like. At least initially.
See what difference that makes.

Though I have that exact same setup and it reconnects without issue.

Steve

spencer99

@stephenw10
Do you reckon its worth contacting BT for a DLM reset to see if that sorts the sync speed issues? Or just wait for the DLM profile to raise the sync speeds over the next week by itself.

stephenw10

Yeah, if it's been bouncing the actual line it will be slow for a while but should improve over time. But that shouldn't be unless the modem was actually rebooting.

spencer99

@stephenw10 Just an update on this, didnt need to call BT for a DLM reset it automatically jumped back up this morning. Allot of the line instability was being caused by a device on my network saturating the connection in the mornings, that lead to that packet loss alarm and the WAN interface reset issue. The gateway monitor action disabled now and I have put a HFSC traffic shaper in place to stop anything saturating the WAN interface to the point of extreme packet loss.

All a little odd to me still given I have never had to implement a traffic shaper or disable the gateway monitor before to have stability even under saturation but hey everything seem to work now.

Many thanks for the help, I'd buy you a beer if I could.

stephenw10

Good result.
As an alternative you can just tune the monitoring settings to better match your line. Some WANs have far higher latency under load.
You might also try an FQ_CODEL setup instead of HFSC.

Steve