WAN periodically Rebooting
-
Sorry for asking 'basic questions',..
Running pfsense 2.7.2,.. connected to provider (BT) via an old BT (huawei) modem,.. this config has been working fine for several years until recently.
When I have noticed more WAN modem reconnects and reboots of WAN... the base system OS,.. has been running for some 110days since last reboot,.. without issue.
I reboot the WAN once per week, ( Sunday 00:00 ),.. via Pfsense CRON..
I have tried looking through the logs,.. but how do I filter down on WAN reconnects,.. I need help,.. I appreciate BT forces reconnects to ensure external IP addresses are not fixed,.. and they can charge extra,.. but of late I seem to be getting more WAN reboots than normal.
Is anyone able to offer some advice/assistance with my debugging etc
Many tx -
Two possible scenarios :
pfSense took the WAN down by itself. There is a process called dpinger that pings to somewhere to the outside, a nearby gateway, or also, very popular, (and dangerous) : they ping 8.8.8.8.
If these pings start to fail : no answer anymore, this dpinger will 'reset' the WAN connection.It can also be modem - or the ones who control the modem (Huawei ?) that takes his side of the connection (a LAN from the standpoint of that modem device) is something happened to the upstream connection.
Start by putting a simple switch between your pfSense and the modem.
-
-
Some of those older HG612s have seen a lot of hours and become unreliable. I have two waiting to be recycled here.
BT bouncing the connection (PPPoE) should not cause a loss of link on the NIC connected to the modem. So filter the logs for:
link state changed
-
@stephenw10 Many tx for replies,.. How do I search for 'link state changed',..
I am in the status > system logs,...
I do not see any search option from the top level list of :- system, firewall, DHCP, Authentication, IPSEC, PPP,.. etc..Yes my HG612 has served me well,.. and yes it does run hot sometimes,.. is anyone able to offer suggestions on a good replacement,.. as I do feel a little vulnerable as I have no replacement for the Modem... my provider is BT, with a standard FTTC,.. 72Mbit type copper connection,.. ie NOT FTTP..
Tx -
@Gertjan said in WAN periodically Rebooting:
Many tx for your replay,...Start by putting a simple switch between your pfSense and the modem.
How exactly do you mean,.. something that will enable to power cycle the modem???
-
The ECI equivalent modem is often more reliable. The HG612 is usually better if the upstream equipment in the cab is Huawei.
The g.fast modems (MT992) that were very expensive at one time are now cheap as BT stopped rolling out g.fast. Don't ask how much I paid for one!
They will do standard VDSL2 too and seem pretty good. Never had an issue with the one I have.Search the logs like this:
-
@stephenw10 Got-it,.. Never got to that menu before,. Thankyou..
I get the following:-Jul 30 00:24:34 kernel igb1: link state changed to UP
Jul 30 00:24:30 kernel igb1: link state changed to DOWN
Jul 30 00:24:29 kernel igb1: link state changed to UP
Jul 30 00:24:24 kernel igb1: link state changed to DOWNand I have 24 events, 12 ( up-down ) cycles at 24 seconds past midnight..
although WAN 'last reset' just over 12:38hrs ago which does not correlate time wise with these event,.. which occured 15:38hrs ago -
@diyhouse said in WAN periodically Rebooting:
and I have 24 events, 12 ( up-down ) cycles at 24 seconds past midnight..
All from the same day or are you saying the NIC bounces everyday at the same?
Also I assume igb1 is actually the parent interface for the PPPOe connection?
It's possible to unlock those modems which then gives you access to useful data such as uptime which would tell you if the modem is rebooting:
Product type EchoLife HG612 Device ID 10C61F-21530315408K23024294 Hardware version VER.B Software version V100R001C01B030SP08 Firmware version A2pv6C038m.d24j Batch number BC1P6.030.A2pv6C038m.d24j System up time 231 days 10 hours 23 minutes 50 seconds
The MT992 cannot be accessed unfortunately.
-
@stephenw10 said in WAN periodically Rebooting:
Also I assume igb1 is actually the parent interface for the PPPOe connection?
Humm,.. just checked,.. No,.. PPPOe is on igb0,..
and LAN1 is on igb1,.. which connects to a single 8port netgear switch...
Not saying this happens every night at just gone midnight,.. its just the last events it filtered... -
Ah, OK well if there are no events for igb0 then the modem is not rebooting.
Filtering by
newwanip
should show you every time the PPPoE reconnected. -
@stephenw10
Ah yes that filter finds the eventsAug 1 13:15:52 php-fpm 88740 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 109.151.224.138 -> 109.151.224.138 - Restarting packages. Aug 1 13:15:50 php-fpm 88740 /rc.newwanip: Creating rrd update script Aug 1 13:15:50 php-fpm 88740 /rc.newwanip: Resyncing OpenVPN instances for interface 1_WAN. Aug 1 13:15:50 php-fpm 88740 /rc.newwanip: Gateway, none 'available' for inet6, use the first one configured. 'LAN1_DHCP6' Aug 1 13:15:50 php-fpm 88740 /rc.newwanip: Default gateway setting Interface 1_WAN_PPPOE Gateway as default. Aug 1 13:15:50 php-fpm 88740 /rc.newwanip: Gateway, none 'available' for inet, use the first one configured. '1_WAN_PPPOE' Aug 1 13:15:45 php-fpm 88740 /rc.newwanip: rc.newwanip: on (IP address: 109.151.224.138) (interface: 1_WAN[wan]) (real interface: pppoe0). Aug 1 13:15:45 php-fpm 88740 /rc.newwanip: rc.newwanip: Info: starting on pppoe0. Aug 1 13:15:44 check_reload_status 430 rc.newwanip starting pppoe0 Jul 31 02:31:41 php-fpm 34142 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 109.145.193.70 -> 109.151.224.138 - Restarting packages. Jul 31 02:31:39 php-fpm 34142 /rc.newwanip: Creating rrd update script Jul 31 02:31:39 php-fpm 34142 /rc.newwanip: Resyncing OpenVPN instances for interface 1_WAN. Jul 31 02:31:39 php-fpm 34142 /rc.newwanip: IP Address has changed, killing states on former IP Address 109.145.193.70. Jul 31 02:31:39 php-fpm 34142 /rc.newwanip: Gateway, none 'available' for inet6, use the first one configured. 'LAN1_DHCP6' Jul 31 02:31:39 php-fpm 34142 /rc.newwanip: Default gateway setting Interface 1_WAN_PPPOE Gateway as default. Jul 31 02:31:39 php-fpm 34142 /rc.newwanip: Gateway, none 'available' for inet, use the first one configured. '1_WAN_PPPOE' Jul 31 02:31:33 php-fpm 34142 /rc.newwanip: rc.newwanip: on (IP address: 109.151.224.138) (interface: 1_WAN[wan]) (real interface: pppoe0). Jul 31 02:31:33 php-fpm 34142 /rc.newwanip: rc.newwanip: Info: starting on pppoe0. Jul 31 02:31:32 check_reload_status 430 rc.newwanip starting pppoe0
Although looking deeper at 'link state changed',..
This event,.. seems to occur every morning at 24seconds + or - past midnight,.. and lasts approx 4 or 5 seconds... but not sure how this is related...Aug 2 00:24:12 kernel igb1: link state changed to UP Aug 2 00:24:08 kernel igb1: link state changed to DOWN
-
@diyhouse
also,.. the MT992
@stephenw10 said in WAN periodically Rebooting:The g.fast modems (MT992) that were very expensive at one time are now cheap as BT stopped rolling out g.fast. Don't ask how much I paid for one!
They will do standard VDSL2 too and seem pretty good. Never had an issue with the one I have.
Tx for the suggestion,..Do they need a firmware update like the 612 did?,.. or is this really just PnP...
Seems like a good option,.. and at ยฃ20,.. just as easy to try one, in the fault finding exercise..
Thankyou for the help advice -
@diyhouse
Just looking at log more,.. and using the filter,.. :-) ( love it )
It seems to happen quite a lot,.. sometimes twice a day,... but what causes this,.. is this 'me' or a BT driven event?Aug 1 13:15:44 check_reload_status 430 rc.newwanip starting pppoe0 Jul 31 02:31:32 check_reload_status 430 rc.newwanip starting pppoe0 Jul 31 02:23:55 check_reload_status 430 rc.newwanip starting pppoe0 Jul 31 02:19:56 check_reload_status 430 rc.newwanip starting pppoe0 Jul 31 01:19:43 check_reload_status 430 rc.newwanip starting pppoe0 Jul 30 19:59:49 check_reload_status 430 rc.newwanip starting pppoe0 Jul 30 02:56:35 check_reload_status 430 rc.newwanip starting pppoe0 Jul 29 22:41:06 check_reload_status 430 rc.newwanip starting pppoe0 Jul 29 20:33:10 check_reload_status 430 rc.newwanip starting pppoe0 Jul 29 05:27:56 check_reload_status 430 rc.newwanip starting pppoe0 Jul 28 21:00:39 check_reload_status 430 rc.newwanip starting pppoe0 Jul 28 18:36:59 check_reload_status 430 rc.newwanip starting pppoe0 Jul 28 00:00:05 check_reload_status 430 rc.newwanip starting pppoe0 Jul 27 01:57:13 check_reload_status 430 rc.newwanip starting pppoe0 Jul 26 02:07:46 check_reload_status 430 rc.newwanip starting pppoe0 Jul 25 22:41:01 check_reload_status 430 rc.newwanip starting pppoe0 Jul 25 21:53:02 check_reload_status 430 rc.newwanip starting pppoe0 Jul 25 14:49:49 check_reload_status 430 rc.newwanip starting pppoe0 Jul 25 14:41:52 check_reload_status 430 rc.newwanip starting pppoe0 Jul 25 14:38:56 check_reload_status 430 rc.newwanip starting pppoe0 Jul 25 14:36:25 check_reload_status 430 rc.newwanip starting pppoe0 Jul 24 22:51:35 check_reload_status 430 rc.newwanip starting pppoe0 Jul 24 14:23:00 check_reload_status 430 rc.newwanip starting pppoe0 Jul 24 10:58:26 check_reload_status 430 rc.newwanip starting pppoe0 Jul 24 10:21:06 check_reload_status 430 rc.newwanip starting pppoe0 Jul 22 21:54:20 check_reload_status 430 rc.newwanip starting pppoe0 Jul 22 19:41:35 check_reload_status 430 rc.newwanip starting pppoe0 Jul 22 19:36:55 check_reload_status 430 rc.newwanip starting pppoe0 Jul 22 19:13:09 check_reload_status 430 rc.newwanip starting pppoe0 Jul 22 18:55:55 check_reload_status 430 rc.newwanip starting pppoe0 Jul 22 18:53:17 check_reload_status 430 rc.newwanip starting pppoe0 Jul 22 18:19:39 check_reload_status 430 rc.newwanip starting pppoe0
-
@diyhouse said in WAN periodically Rebooting:
Although looking deeper at 'link state changed',..
This event,.. seems to occur every morning at 24seconds + or - past midnight,.. and lasts approx 4 or 5 seconds... but not sure how this is related...That seems suspicious. What is that connected to? Is that device resetting?
That interface flapping will trigger a bunch of stuff even if it's not the WAN.@diyhouse said in WAN periodically Rebooting:
Do they need a firmware update like the 612 did?,.. or is this really just PnP...
I've never seen a firmware update but they don't have a user accessible interface either. AFAIK is really is PNP. There was another user here testing it if I could fine it. At one time those were all >ยฃ200!
@diyhouse said in WAN periodically Rebooting:
It seems to happen quite a lot,.. sometimes twice a day,... but what causes this,.. is this 'me' or a BT driven event?
Check the ppp logs. It should show what drove the disconnect event. It's usually the remote side.
For example this is something local closing it:Jul 29 19:17:41 ppp 41282 caught fatal signal TERM Jul 29 19:17:41 ppp 41282 [opt4] IFACE: Close event Jul 29 19:17:41 ppp 41282 [opt4] IPCP: Close event Jul 29 19:17:41 ppp 41282 [opt4] IPCP: state change Opened --> Closing Jul 29 19:17:41 ppp 41282 [opt4] IPCP: SendTerminateReq #4 Jul 29 19:17:41 ppp 41282 [opt4] IPCP: LayerDown
This is some upstream problem:
Nov 23 08:19:16 ppp 14046 [opt4_link0] LCP: no reply to 5 echo request(s) Nov 23 08:19:16 ppp 14046 [opt4_link0] LCP: peer not responding to echo requests Nov 23 08:19:16 ppp 14046 [opt4_link0] LCP: state change Opened --> Stopping Nov 23 08:19:16 ppp 14046 [opt4_link0] Link: Leave bundle "opt4" Nov 23 08:19:16 ppp 14046 [opt4] Bundle: Status update: up 0 links, total bandwidth 9600 bps Nov 23 08:19:16 ppp 14046 [opt4] IPCP: Close event
Note I had to go back to November to find one.
-
@stephenw10 said in WAN periodically Rebooting:
Looking into logs around 13:15 today,.. things look like this,
where there are many things happening,.. none of which look good, WAN failing up down layerup etc etc.. even to my untrained eye,.. but I hope will mean something to a 'trained eye of pfsense,..
..Back to November,.. do you have a fixed IP,.. and are you maybe with another provider ( Not BT),.. as my last reboot, was intentional some 110days ago,.. any other 'house failures' as long as there less than 10hrs do not cause an issue... ( as Big battery on UPS )
I seek your advice,.. etc ,.. should I just buy an MT992? and replace modem?
Many TxAug 1 15:32:55 ppp 90375 [wan_link0] LCP: no reply to 2 echo request(s) Aug 1 15:32:45 ppp 90375 [wan_link0] LCP: no reply to 1 echo request(s) Aug 1 13:15:46 ppp 90375 [wan_link0] rec'd unexpected protocol IPV6CP, rejecting Aug 1 13:15:44 ppp 90375 [wan] IFACE: Add description "1_WAN" Aug 1 13:15:44 ppp 90375 [wan] IFACE: Rename interface ng0 to pppoe0 Aug 1 13:15:44 ppp 90375 [wan] IFACE: Up event Aug 1 13:15:43 ppp 90375 [wan] 109.151.224.138 -> 172.16.12.102 Aug 1 13:15:43 ppp 90375 [wan] IPCP: LayerUp Aug 1 13:15:43 ppp 90375 [wan] IPCP: state change Ack-Sent --> Opened Aug 1 13:15:43 ppp 90375 [wan] SECDNS 81.139.57.100 Aug 1 13:15:43 ppp 90375 [wan] PRIDNS 81.139.56.100 Aug 1 13:15:43 ppp 90375 [wan] IPADDR 109.151.224.138 Aug 1 13:15:43 ppp 90375 [wan] IPCP: rec'd Configure Ack #52 (Ack-Sent) Aug 1 13:15:43 ppp 90375 [wan] SECDNS 81.139.57.100 Aug 1 13:15:43 ppp 90375 [wan] PRIDNS 81.139.56.100 Aug 1 13:15:43 ppp 90375 [wan] IPADDR 109.151.224.138 Aug 1 13:15:43 ppp 90375 [wan] IPCP: SendConfigReq #52 Aug 1 13:15:43 ppp 90375 [wan] SECDNS 81.139.57.100 Aug 1 13:15:43 ppp 90375 [wan] PRIDNS 81.139.56.100 Aug 1 13:15:43 ppp 90375 [wan] 109.151.224.138 is OK Aug 1 13:15:43 ppp 90375 [wan] IPADDR 109.151.224.138 Aug 1 13:15:43 ppp 90375 [wan] IPCP: rec'd Configure Nak #51 (Ack-Sent) Aug 1 13:15:43 ppp 90375 [wan_link0] rec'd unexpected protocol IPV6CP, rejecting Aug 1 13:15:43 ppp 90375 [wan] SECDNS 0.0.0.0 Aug 1 13:15:43 ppp 90375 [wan] PRIDNS 0.0.0.0 Aug 1 13:15:43 ppp 90375 [wan] IPADDR 0.0.0.0 Aug 1 13:15:43 ppp 90375 [wan] IPCP: SendConfigReq #51 Aug 1 13:15:43 ppp 90375 [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Aug 1 13:15:43 ppp 90375 [wan] IPCP: rec'd Configure Reject #50 (Ack-Sent) Aug 1 13:15:43 ppp 90375 [wan] IPCP: state change Req-Sent --> Ack-Sent Aug 1 13:15:43 ppp 90375 [wan] IPADDR 172.16.12.102 Aug 1 13:15:43 ppp 90375 [wan] IPCP: SendConfigAck #185 Aug 1 13:15:43 ppp 90375 [wan] 172.16.12.102 is OK Aug 1 13:15:43 ppp 90375 [wan] IPADDR 172.16.12.102 Aug 1 13:15:43 ppp 90375 [wan] IPCP: rec'd Configure Request #185 (Req-Sent) Aug 1 13:15:43 ppp 90375 [wan_link0] rec'd unexpected protocol IPV6CP, rejecting Aug 1 13:15:43 ppp 90375 [wan] SECDNS 0.0.0.0 Aug 1 13:15:43 ppp 90375 [wan] PRIDNS 0.0.0.0 Aug 1 13:15:43 ppp 90375 [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Aug 1 13:15:43 ppp 90375 [wan] IPADDR 0.0.0.0 Aug 1 13:15:43 ppp 90375 [wan] IPCP: SendConfigReq #50 Aug 1 13:15:43 ppp 90375 [wan] IPCP: state change Starting --> Req-Sent Aug 1 13:15:43 ppp 90375 [wan] IPCP: Up event Aug 1 13:15:43 ppp 90375 [wan] IPCP: LayerStart Aug 1 13:15:43 ppp 90375 [wan] IPCP: state change Initial --> Starting Aug 1 13:15:43 ppp 90375 [wan] IPCP: Open event Aug 1 13:15:43 ppp 90375 [wan] Bundle: Status update: up 1 link, total bandwidth 64000 bps Aug 1 13:15:43 ppp 90375 [wan_link0] Link: Join bundle "wan" Aug 1 13:15:43 ppp 90375 [wan_link0] Link: Matched action 'bundle "wan" ""' Aug 1 13:15:43 ppp 90375 [wan_link0] LCP: authorization successful Aug 1 13:15:43 ppp 90375 [wan_link0] MESG: CHAP authentication success Aug 1 13:15:43 ppp 90375 [wan_link0] CHAP: rec'd SUCCESS #1 len: 31 Aug 1 13:15:43 ppp 90375 [wan_link0] CHAP: sending RESPONSE #1 len: 52 Aug 1 13:15:43 ppp 90375 [wan_link0] CHAP: Using authname "green-light@service.btclick.com" Aug 1 13:15:43 ppp 90375 [wan_link0] Name: "acc-aln2.tbs" Aug 1 13:15:43 ppp 90375 [wan_link0] CHAP: rec'd CHALLENGE #1 len: 51 Aug 1 13:15:43 ppp 90375 [wan_link0] LCP: LayerUp Aug 1 13:15:43 ppp 90375 [wan_link0] LCP: auth: peer wants CHAP, I want nothing Aug 1 13:15:43 ppp 90375 [wan_link0] LCP: state change Ack-Sent --> Opened Aug 1 13:15:43 ppp 90375 [wan_link0] MAGICNUM 0xc47d9da9 Aug 1 13:15:43 ppp 90375 [wan_link0] MRU 1492 Aug 1 13:15:43 ppp 90375 [wan_link0] LCP: rec'd Configure Ack #36 (Ack-Sent) Aug 1 13:15:43 ppp 90375 [wan_link0] MAGICNUM 0xc47d9da9 Aug 1 13:15:43 ppp 90375 [wan_link0] MRU 1492 Aug 1 13:15:43 ppp 90375 [wan_link0] LCP: SendConfigReq #36 Aug 1 13:15:43 ppp 90375 [wan_link0] PROTOCOMP Aug 1 13:15:43 ppp 90375 [wan_link0] LCP: rec'd Configure Reject #35 (Ack-Sent) Aug 1 13:15:43 ppp 90375 [wan_link0] LCP: state change Req-Sent --> Ack-Sent Aug 1 13:15:43 ppp 90375 [wan_link0] MAGICNUM 0x7c14f295 Aug 1 13:15:43 ppp 90375 [wan_link0] AUTHPROTO CHAP MD5 Aug 1 13:15:43 ppp 90375 [wan_link0] MRU 1492 Aug 1 13:15:43 ppp 90375 [wan_link0] LCP: SendConfigAck #75 Aug 1 13:15:43 ppp 90375 [wan_link0] MAGICNUM 0x7c14f295 Aug 1 13:15:43 ppp 90375 [wan_link0] AUTHPROTO CHAP MD5 Aug 1 13:15:43 ppp 90375 [wan_link0] MRU 1492 Aug 1 13:15:43 ppp 90375 [wan_link0] LCP: rec'd Configure Request #75 (Req-Sent) Aug 1 13:15:43 ppp 90375 [wan_link0] MAGICNUM 0xc47d9da9 Aug 1 13:15:43 ppp 90375 [wan_link0] MRU 1492 Aug 1 13:15:43 ppp 90375 [wan_link0] PROTOCOMP Aug 1 13:15:43 ppp 90375 [wan_link0] LCP: SendConfigReq #35 Aug 1 13:15:43 ppp 90375 [wan_link0] LCP: state change Starting --> Req-Sent Aug 1 13:15:43 ppp 90375 [wan_link0] LCP: Up event Aug 1 13:15:43 ppp 90375 [wan_link0] Link: UP event Aug 1 13:15:43 ppp 90375 [wan_link0] PPPoE: connection successful Aug 1 13:15:43 ppp 90375 PPPoE: rec'd ACNAME "acc-aln2.tbs" Aug 1 13:15:43 ppp 90375 [wan_link0] PPPoE: Connecting to '' Aug 1 13:15:43 ppp 90375 [wan_link0] Link: reconnection attempt 3 Aug 1 13:15:39 ppp 90375 [wan_link0] Link: reconnection attempt 3 in 4 seconds Aug 1 13:15:39 ppp 90375 [wan_link0] LCP: Down event Aug 1 13:15:39 ppp 90375 [wan_link0] Link: DOWN event Aug 1 13:15:39 ppp 90375 [wan_link0] PPPoE connection timeout after 9 seconds Aug 1 13:15:30 ppp 90375 [wan_link0] PPPoE: Connecting to '' Aug 1 13:15:30 ppp 90375 [wan_link0] Link: reconnection attempt 2 Aug 1 13:15:28 ppp 90375 [wan_link0] Link: reconnection attempt 2 in 2 seconds Aug 1 13:15:28 ppp 90375 [wan_link0] LCP: Down event Aug 1 13:15:28 ppp 90375 [wan_link0] Link: DOWN event Aug 1 13:15:28 ppp 90375 [wan_link0] PPPoE connection timeout after 9 seconds Aug 1 13:15:19 ppp 90375 [wan_link0] PPPoE: Connecting to '' Aug 1 13:15:19 ppp 90375 [wan_link0] Link: reconnection attempt 1 Aug 1 13:15:18 ppp 90375 [wan_link0] Link: reconnection attempt 1 in 1 seconds Aug 1 13:15:18 ppp 90375 [wan_link0] LCP: LayerDown Aug 1 13:15:18 ppp 90375 [wan] Bundle: Last link has gone, no links for bw-manage defined Aug 1 13:15:18 ppp 90375 [wan] IPCP: state change Closing --> Initial Aug 1 13:15:18 ppp 90375 [wan] Bundle: No NCPs left. Closing links... Aug 1 13:15:18 ppp 90375 [wan] IPCP: LayerFinish Aug 1 13:15:18 ppp 90375 [wan] IPCP: Down event Aug 1 13:15:18 ppp 90375 [wan] IFACE: Set description "1_WAN" Aug 1 13:15:18 ppp 90375 [wan] IFACE: Rename interface pppoe0 to pppoe0 Aug 1 13:15:18 ppp 90375 [wan] IFACE: Down event Aug 1 13:15:18 ppp 90375 [wan] IFACE: Removing IPv4 address from pppoe0 failed(IGNORING for now. This should be only for PPPoE friendly!): Can't assign requested address Aug 1 13:15:17 ppp 90375 [wan] IPCP: LayerDown Aug 1 13:15:17 ppp 90375 [wan] IPCP: SendTerminateReq #49 Aug 1 13:15:17 ppp 90375 [wan] IPCP: state change Opened --> Closing Aug 1 13:15:17 ppp 90375 [wan] IPCP: Close event Aug 1 13:15:17 ppp 90375 [wan] Bundle: Status update: up 0 links, total bandwidth 9600 bps Aug 1 13:15:17 ppp 90375 [wan_link0] Link: Leave bundle "wan" Aug 1 13:15:17 ppp 90375 [wan_link0] LCP: state change Opened --> Starting Aug 1 13:15:17 ppp 90375 [wan_link0] LCP: Down event Aug 1 13:15:17 ppp 90375 [wan_link0] Link: DOWN event Aug 1 13:15:17 ppp 90375 [wan_link0] PPPoE: connection closed Aug 1 13:15:17 ppp 90375 [wan_link0] LCP: no reply to 3 echo request(s) Aug 1 13:15:07 ppp 90375 [wan_link0] LCP: no reply to 2 echo request(s) Aug 1 13:14:57 ppp 90375 [wan_link0] LCP: no reply to 1 echo request(s)
-
Well the modem is not losing link to pfSense so it's not rebooting.
Those logs show it stops seeing responses from upstream but not the count of 5 missed replies that would trigger a reconnect. However the connection is them promptly closed which implies something was sent from upstream. If so a different modem might not make any difference.
However given the age of the HG612 I would probably try replacing it. An MT992 is likely to be better at using the available line conditions anyway.
What sort of connections speeds do you get? -
@stephenw10
Well using webtool 'speedtest',.. I get 40Mbps download, ( I am surprised ) and 15Mps up,.. with a ping of 15ms. No other traffic as far as I can see,.. but who knows what is up stream. at 9PM at nightNow many moons ago when I 1st setup pfsense I seem to recall getting 56Mbps,.. and prob 20Mbps Up,..
compared to 72Mbps the the offical BT, Modem,.. but I was happy with '56',.. as the 72 was only BT reporting on itself,...
Having 'lost' 16Mbps download,.. something would seem to be Off,...
.... off to order MT992.... -
@diyhouse MT992 order,.. brand new one!!,.. just no power block,..
But have spare for old one if required,.. and I supply it from a UPS anyway...
So should be good for a few years,.. of 24/7 running.
Thinking about it the HG612 must have been running for 3 or 4 yrs,.. solid,.. and it does sometimes run warm, especially during hot summers,.. like ATM in the UK.. 40C ambient in loft, (must find invoice to see how long),.. Hummm -
Could also be your line conditions have deteriorated. The unlocked HG612 gives nice stats for that:
It really is a shame the MT992 is locked down. I'm sure all that data is in there.
-
@stephenw10
Hi Steve,.. My new MT992 has just arrived,... minus power supply as stated before,,,.
Just covering the 'idiot guide question',.. supply requirements 12v @1amp,... I ASSUME,... centre pin is plus,.. and barrel outer is -Ve... as per normal convention,.. as it does not state on MT992...
Many Tx