Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    WAN periodically Rebooting,.. Take Two

    Scheduled Pinned Locked Moved General pfSense Questions
    19 Posts 4 Posters 461 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      Ok, so to be clear the WAN is disconnecting, nothing is actually rebooting?

      It really sounds like a line issue or some upstream fault TBH.

      D 1 Reply Last reply Reply Quote 0
      • D
        diyhouse @stephenw10
        last edited by

        @stephenw10 said in WAN periodically Rebooting,.. Take Two:

        nothing is actually rebooting

        Correct, WAN disconnects,.. it can then take a Draytek reboot,.. before 'normal service is resumed,.. as they say.

        D 1 Reply Last reply Reply Quote 0
        • D
          diyhouse @diyhouse
          last edited by

          @diyhouse Update :-
          Well guys,.. Mr. BT paid a visit yesterday,.. in the 'guise of Kelly communication.
          Engineer did his own tests, as you would expect, and was actually understanding to my problem of the connection did not stay up for more than a few days...
          Initially, he said he was going to the 'cabinet', to give me some more fibres,.. ( why two I do not know ),.. but these are allocated by BT central command you might say,.. and are administered remotely...
          When engineer returned he said he had NOT changed the fibres,.. but central command, had removed manually set 'capping limits' that existed on my line.
          OK,.. So performance had improved,.. download was better,.. up from 55 to 75Mbps,.. as a before and after,.. although upload only went from 10 to 11Mbps ,.. so nothing mega,. Although Eng. test unit said upload was around 15Mbps.
          As for how this affects my long term connectivity, neither I or the Kelly Eng. engineer could equate.
          So its now another waiting game,.. to see how long the connection holds up.
          As of typing this the following day, my rates are at 75/11Mbps.. so we shall see..

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            🤞

            D 1 Reply Last reply Reply Quote 0
            • D
              diyhouse @stephenw10
              last edited by

              @stephenw10 And for my next instalment in my connection saga,...
              (Hope this is of interest to someone,. and not just my waffling)
              following the Kelly Communication visit,. my WAN stayed up for 5 Days,.. then that evening had a real tantrum,. dropping and re-connecting 4 or 5 times real PITA..
              Escalated to BT,.. Again, ( I was not a happy bunny )... unable to book visit,.. but engineer rang the following day,.. said all looked good ( here we go again I think ),.. from his remote testing,. discussed history,.. and previous engineer visits,.. clarified what Kelly Eng had done,.. and we concluded 'not a lot'.
              Said he could attend premises in 20mins,.. Yes pls.
              So,.. BT eng,. checked the line for reference,.. said its performance was OK'ish, but was not at the level he would expect for a line that was only 2 hundred metres from a FTTC box... He compared my line to others on the same pole,.. ie my neighbours,.. and they were getting slightly better performance,.. which although not perfect was an indicator something might be up!! ( they were getting 90 to a 105 download, where as I was is the 80's )
              He checked my copper line to the premises,.. ( this involved placing a 'gizzmo' into my socket at the premises,.. and then doing some checks at he cabinat, at the other end of the copper, and that was all good.
              He then did some re-config,..
              As I understand,.. a fibre comes from the exchange to the cabinet,.. hence FTTC,.. it is then somehow multiplexed across numerous copper connections,.. ( so splitting the bandwidth of the fibre to multiple copper pairs )... this switching is configured with software by changing a port ID's,... to give a different link into the fibre.
              BT Engineer then allocated my premises a new port, at the cabinat.
              On return to my premises further test showed speed improvements, if not amazing,. what was encouraging is the fault packet count was at zero, running over a short test period. ( previously FEC was always counting up )
              My current rate speed is at 73/11Mbps... and I have been running for some 12hrs without a drop,..
              So definitely early days,.. but even the BT eng. was upbeat about having fixed my problem, and for the first time I feel something concrete has been done,.. based on data and investigation,.. other than just previously ticking boxes,.. 'your performanace shows as 71/20,.. so you should be fine' ( so stop complaining😠 ).

              GertjanG 1 Reply Last reply Reply Quote 0
              • GertjanG
                Gertjan @diyhouse
                last edited by

                @diyhouse

                Do I get this right : you've fiber arriving at 200 meters, and the final delivery has to come over copper (here are the crusty connections, sun electromagnetic waves, probably pppoe etc) ?

                No "help me" PM's please. Use the forum, the community will thank you.
                Edit : and where are the logs ??

                D 1 Reply Last reply Reply Quote 0
                • D
                  diyhouse @Gertjan
                  last edited by

                  @Gertjan Yes,.. there is a short link from the exchange via fibre to the cabinat, and the cabinat is approx. 200m away from my property,.. but still a relatively short link in copper term.
                  But as copper tests showed my link appeared ok,.. although engineer did say he recently encountered a customer where the copper had worn,.. but only showed up as a problem when it was windy.

                  GertjanG 1 Reply Last reply Reply Quote 0
                  • GertjanG
                    Gertjan @diyhouse
                    last edited by

                    @diyhouse

                    Ok, thanks.
                    I'm amazed : plain copper (POTS ?) wires, non twisted, not shielded, and its possible to pump 70 Mbits over them ...

                    No "help me" PM's please. Use the forum, the community will thank you.
                    Edit : and where are the logs ??

                    N 1 Reply Last reply Reply Quote 0
                    • N
                      netblues @Gertjan
                      last edited by

                      @Gertjan said in WAN periodically Rebooting,.. Take Two:

                      I'm amazed : plain copper (POTS ?) wires, non twisted, not shielded, and its possible to pump 70 Mbits over them ..

                      Typical telephone cabling. Twisted pair. Nothing special obviously.
                      A typical fttc installation with a dslam and vdsl over telephone wiring.
                      Its just that the op isn't familiar with the terminology.

                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        Yeah they are twisted pairs. And 80Mbps is pretty normal for that. g.fast over those same wires and distance could see 200-300Mbps. I'm at ~300m from the cabinet and get >140Mbps. But bring on FTTP. Can't come soon enough IMO!

                        D 1 Reply Last reply Reply Quote 0
                        • D
                          diyhouse @stephenw10
                          last edited by

                          @stephenw10
                          IMG-20250415-WA0004.jpg
                          Just for some more info / interest,.. the BT engineer sent me some screen shots,..
                          This one shows the speeds of 'other' customers on the same pole as myself,.. all I know is that I am the bottom bottom one of the list,... and although still within spec., the engineer was suspicious of why my Max speed was not closer to the 90's.
                          which spurred him on more to pursue a little further..

                          Following a 'lift and shift' operation at the cabinet,.. to reallocate me to a new port,.. this is the result, where the system shows my Max attn. speed now in the 94+Mbps region...
                          IMG-20250416-WA0002.jpg

                          N 1 Reply Last reply Reply Quote 0
                          • N
                            netblues @diyhouse
                            last edited by

                            @diyhouse All of this was something of concern, ten years ago.
                            Since you have ftth as an option, there is no point wasting time with xdsl.

                            The pair you have, will be invalidated the moment some neighbor changes something. Equipment, speed etc.
                            Crosstalk will kick in, and you 'll be back to square one.

                            1 Reply Last reply Reply Quote 1
                            • stephenw10S
                              stephenw10 Netgate Administrator
                              last edited by

                              Meh. I've never had much of an issue with FTTC. It pretty much 'just works' here and I don't think I have anything special.

                              But, yes, I will switch to FTTP the second they make it available. 😉

                              D 1 Reply Last reply Reply Quote 0
                              • D
                                diyhouse @stephenw10
                                last edited by

                                @stephenw10
                                Just a quick update to folks,.. well its been 7 days ( on its way to 8 ), as I type,.. with continuous internet access,..
                                Well lets just say the WAN has not dropped,.. and for me that is close to a record in the last 12 months.
                                So looking positive since my 3rd ( and lastest ) visit from a BT engineer.

                                N 1 Reply Last reply Reply Quote 1
                                • N
                                  netblues @diyhouse
                                  last edited by

                                  @diyhouse Until the next thunderstorm. 🤡

                                  D 1 Reply Last reply Reply Quote 0
                                  • D
                                    diyhouse @netblues
                                    last edited by

                                    @netblues ......well it got to 24days and a bit I think...
                                    and then:- ( see log below )
                                    Now 24 days is a 'recent record' for me,.. but I will probably give the Draytek,.. in modem mode a whizz now... and see how that fairs...

                                    May 9 14:20:00	sshguard	86378	Now monitoring attacks.
                                    May 9 14:20:00	sshguard	75904	Exiting on signal.
                                    May 9 14:19:14	php_pfb	73267	[pfBlockerNG] filterlog daemon started
                                    May 9 14:19:14	php	72417	[pfBlockerNG] DNSBL parser daemon started
                                    May 9 14:19:13	vnstatd	66864	Monitoring (11): pppoe0 (1000 Mbit) pfsync0 (1000 Mbit) pflog0 (1000 Mbit) igb3.30 (1000 Mbit) igb3.20 (1000 Mbit) igb3.10 (1000 Mbit) igb3 (1000 Mbit) igb2 (10 Mbit) igb1 (1000 Mbit) igb0 (1000 Mbit) enc0 (1000 Mbit)
                                    May 9 14:19:13	vnstatd	66864	Data retention: 48 5MinuteHours, 4 HourlyDays, 62 DailyDays, 25 MonthlyMonths, -1 YearlyYears, 20 TopDayEntries
                                    May 9 14:19:13	vnstatd	66864	vnStat daemon 2.11 (pid:66864 uid:0 gid:0, SQLite 3.43.1)
                                    May 9 14:19:13	tail_pfb	71755	[pfBlockerNG] Firewall Filter Service started
                                    May 9 14:19:13	vnstatd	70720	Error: pidfile "/var/run/vnstat/vnstat.pid" lock failed (Resource temporarily unavailable), exiting.
                                    May 9 14:19:13	lighttpd_pfb	69222	[pfBlockerNG] DNSBL Webserver started
                                    May 9 14:19:13	php_pfb	66824	[pfBlockerNG] filterlog daemon stopped
                                    May 9 14:19:13	tail_pfb	65555	[pfBlockerNG] Firewall Filter Service stopped
                                    May 9 14:19:13	lighttpd_pfb	65452	[pfBlockerNG] DNSBL Webserver stopped
                                    May 9 14:19:13	vnstatd	71246	SIGTERM received, exiting.
                                    May 9 14:19:03	vnstatd	48329	Error: pidfile "/var/run/vnstat/vnstat.pid" lock failed (Resource temporarily unavailable), exiting.
                                    May 9 14:19:03	bandwidthd	48054	Packet Encoding: Ethernet
                                    May 9 14:19:03	bandwidthd	48297	Packet Encoding: Ethernet
                                    May 9 14:19:03	bandwidthd	47899	Packet Encoding: Ethernet
                                    May 9 14:19:03	bandwidthd	48297	Opening igb1
                                    May 9 14:19:03	bandwidthd	48232	Packet Encoding: Ethernet
                                    May 9 14:19:03	bandwidthd	48054	Opening igb1
                                    May 9 14:19:03	bandwidthd	47899	Opening igb1
                                    May 9 14:19:03	bandwidthd	48232	Opening igb1
                                    May 9 14:19:03	bandwidthd	47044	Packet Encoding: Ethernet
                                    May 9 14:19:03	bandwidthd	47044	Opening igb1
                                    May 9 14:19:03	bandwidthd	47391	Packet Encoding: Ethernet
                                    May 9 14:19:03	bandwidthd	47039	Packet Encoding: Ethernet
                                    May 9 14:19:03	bandwidthd	47039	Opening igb1
                                    May 9 14:19:03	bandwidthd	46692	Packet Encoding: Ethernet
                                    May 9 14:19:03	bandwidthd	47391	Opening igb1
                                    May 9 14:19:03	bandwidthd	46692	Opening igb1
                                    May 9 14:19:03	bandwidthd	45743	Monitoring subnet 192.168.3.0 with netmask 255.255.255.0
                                    May 9 14:19:03	bandwidthd	45500	Monitoring subnet 192.168.3.0 with netmask 255.255.255.0
                                    May 9 14:19:03	php-fpm	30317	/rc.start_packages: The command '/usr/local/etc/rc.d/bandwidthd.sh stop' returned exit code '1', the output was 'killall: warning: kill -TERM 35725: No such process killall: warning: kill -TERM 35150: No such process killall: warning: kill -TERM 36240: No such process killall: warning: kill -TERM 35923: No such process'
                                    May 9 14:19:01	php-fpm	30317	/rc.start_packages: Restarting/Starting all packages.
                                    May 9 14:19:00	check_reload_status	430	Reloading filter
                                    May 9 14:19:00	check_reload_status	430	Starting packages
                                    May 9 14:19:00	php-fpm	7306	/rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 109.145.193.45 -> 109.145.193.45 - Restarting packages.
                                    May 9 14:18:59	php-fpm	33256	/rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. 'LAN1_DHCP6'
                                    May 9 14:18:59	php-fpm	33256	/rc.openvpn: Gateway, none 'available' for inet, use the first one configured. '1_WAN_PPPOE'
                                    May 9 14:18:58	php-fpm	7306	/rc.newwanip: Creating rrd update script
                                    May 9 14:18:58	php-fpm	7306	/rc.newwanip: Resyncing OpenVPN instances for interface 1_WAN.
                                    May 9 14:18:58	php-fpm	7306	/rc.newwanip: Gateway, none 'available' for inet6, use the first one configured. 'LAN1_DHCP6'
                                    May 9 14:18:58	check_reload_status	430	Reloading filter
                                    May 9 14:18:58	check_reload_status	430	Restarting OpenVPN tunnels/interfaces
                                    May 9 14:18:58	check_reload_status	430	Restarting IPsec tunnels
                                    May 9 14:18:58	check_reload_status	430	updating dyndns 1_WAN_PPPOE
                                    May 9 14:18:58	rc.gateway_alarm	46924	>>> Gateway alarm: 1_WAN_PPPOE (Addr:172.16.12.102 Alarm:1 RTT:0ms RTTsd:0ms Loss:100%)
                                    May 9 14:18:58	php-fpm	7306	/rc.newwanip: Default gateway setting Interface 1_WAN_PPPOE Gateway as default.
                                    May 9 14:18:58	php-fpm	7306	/rc.newwanip: Gateway, none 'available' for inet, use the first one configured. '1_WAN_PPPOE'
                                    May 9 14:18:53	php-fpm	7306	/rc.newwanip: rc.newwanip: on (IP address: 109.145.193.45) (interface: 1_WAN[wan]) (real interface: pppoe0).
                                    May 9 14:18:53	php-fpm	7306	/rc.newwanip: rc.newwanip: Info: starting on pppoe0.
                                    May 9 14:18:52	check_reload_status	430	rc.newwanip starting pppoe0
                                    May 9 14:18:51	check_reload_status	430	Rewriting resolv.conf
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: LayerUp
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: state change Ack-Sent --> Opened
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: rec'd Configure Ack #7 (Ack-Sent)
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: SendConfigReq #7
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: rec'd Configure Nak #6 (Ack-Sent)
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: SendConfigReq #6
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: rec'd Configure Reject #5 (Ack-Sent)
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: state change Req-Sent --> Ack-Sent
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: SendConfigAck #71
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: rec'd Configure Request #71 (Req-Sent)
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: SendConfigReq #5
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: state change Starting --> Req-Sent
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: Up event
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: LayerStart
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: state change Initial --> Starting
                                    May 9 14:18:50	ppp	72354	[wan] IPCP: Open event
                                    May 9 14:18:50	ppp	72354	[wan_link0] LCP: authorization successful
                                    May 9 14:18:50	ppp	72354	[wan_link0] MESG: CHAP authentication success
                                    May 9 14:18:50	ppp	72354	[wan_link0] CHAP: rec'd SUCCESS #1 len: 31
                                    May 9 14:18:50	ppp	72354	[wan_link0] CHAP: sending RESPONSE #1 len: 45
                                    May 9 14:18:50	ppp	72354	[wan_link0] CHAP: Using authname "N014097@hg70.btclick.com"
                                    May 9 14:18:50	ppp	72354	[wan_link0] Name: "acc-aln2.tbs"
                                    May 9 14:18:50	ppp	72354	[wan_link0] CHAP: rec'd CHALLENGE #1 len: 56
                                    May 9 14:18:50	ppp	72354	[wan_link0] LCP: LayerUp
                                    May 9 14:18:50	ppp	72354	[wan_link0] LCP: auth: peer wants CHAP, I want nothing
                                    May 9 14:18:50	ppp	72354	[wan_link0] LCP: state change Ack-Rcvd --> Opened
                                    May 9 14:18:50	ppp	72354	[wan_link0] LCP: SendConfigAck #160
                                    May 9 14:18:50	ppp	72354	[wan_link0] LCP: rec'd Configure Request #160 (Ack-Rcvd)
                                    May 9 14:18:50	ppp	72354	[wan_link0] LCP: state change Req-Sent --> Ack-Rcvd
                                    May 9 14:18:50	ppp	72354	[wan_link0] LCP: rec'd Configure Ack #7 (Req-Sent)
                                    May 9 14:18:50	ppp	72354	[wan_link0] LCP: SendConfigReq #7
                                    May 9 14:18:50	ppp	72354	[wan_link0] LCP: rec'd Configure Reject #6 (Req-Sent)
                                    May 9 14:18:50	ppp	72354	[wan_link0] LCP: SendConfigReq #6
                                    May 9 14:18:47	ppp	72354	[wan_link0] LCP: SendConfigReq #5
                                    May 9 14:18:47	ppp	72354	[wan_link0] LCP: state change Starting --> Req-Sent
                                    May 9 14:18:47	ppp	72354	[wan_link0] LCP: Up event
                                    May 9 14:18:47	ppp	72354	[wan_link0] PPPoE: connection successful
                                    May 9 14:18:47	ppp	72354	PPPoE: rec'd ACNAME "acc-aln2.tbs"
                                    May 9 14:18:45	ppp	72354	[wan_link0] PPPoE: Connecting to ''
                                    May 9 14:18:42	ppp	72354	[wan_link0] LCP: LayerStart
                                    May 9 14:18:42	ppp	72354	[wan_link0] LCP: state change Stopped --> Starting
                                    May 9 14:18:42	ppp	72354	[wan_link0] LCP: Down event
                                    May 9 14:18:42	ppp	72354	[wan_link0] PPPoE: connection closed
                                    May 9 14:18:42	ppp	72354	[wan_link0] LCP: LayerFinish
                                    May 9 14:18:42	ppp	72354	[wan_link0] LCP: state change Stopping --> Stopped
                                    May 9 14:18:40	ppp	72354	[wan_link0] LCP: SendTerminateReq #4
                                    May 9 14:18:38	ppp	72354	[wan_link0] LCP: LayerDown
                                    May 9 14:18:38	ppp	72354	[wan_link0] LCP: SendTerminateReq #3
                                    May 9 14:18:38	ppp	72354	[wan] IPCP: state change Closing --> Initial
                                    May 9 14:18:38	ppp	72354	[wan] IPCP: LayerFinish
                                    May 9 14:18:38	ppp	72354	[wan] IPCP: Down event
                                    May 9 14:18:38	ppp	72354	[wan] IFACE: Removing IPv4 address from pppoe0 failed(IGNORING for now. This should be only for PPPoE friendly!): Can't assign requested address
                                    May 9 14:18:38	check_reload_status	430	Rewriting resolv.conf
                                    May 9 14:18:37	ppp	72354	[wan] IPCP: LayerDown
                                    May 9 14:18:37	ppp	72354	[wan] IPCP: SendTerminateReq #4
                                    May 9 14:18:37	ppp	72354	[wan] IPCP: state change Opened --> Closing
                                    May 9 14:18:37	ppp	72354	[wan] IPCP: Close event
                                    May 9 14:18:37	ppp	72354	[wan_link0] LCP: state change Opened --> Stopping
                                    May 9 14:18:37	ppp	72354	[wan_link0] LCP: peer not responding to echo requests
                                    May 9 14:18:37	ppp	72354	[wan_link0] LCP: no reply to 5 echo request(s)
                                    May 9 14:18:17	ppp	72354	[wan_link0] LCP: no reply to 4 echo request(s)
                                    May 9 14:17:57	ppp	72354	[wan_link0] LCP: no reply to 3 echo request(s)
                                    May 9 14:17:37	ppp	72354	[wan_link0] LCP: no reply to 2 echo request(s)
                                    May 9 14:17:17	ppp	72354	[wan_link0] LCP: no reply to 1 echo request(s)
                                    May 9 14:15:11	php	24200	[pfBlockerNG] No changes to Firewall rules, skipping Filter Reload
                                    May 9 14:15:00	php	24200	[pfBlockerNG] Starting cron process.
                                    
                                    1 Reply Last reply Reply Quote 1
                                    • First post
                                      Last post
                                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.