WAN periodically Rebooting,.. Take Two
-
@diyhouse said in WAN periodically Rebooting,.. Take Two:
And Yes the configure worked for a while,. ( few days ),.. but then got into the reconnecting cycle,.. after nearly a week I grew tired on the Draytek,.. as it was not very good and reconnecting,.. or sometimes recognising there was no IP connection to the WAN,... ( requiring a physical reboot ),
Be ware : if your upstream ( Draytek, whatever) router / modem / whatever can't establish a connection over whatever you use as an ISP connection, then pfSense, or any other device you've hookup up behind this Draytec (or other) can't do any better.
You didn't mention, so I'll do : when you activate your Draytek in router mode, what is network IP range of it's LAN ?
If its 192.168.1.x/24, your pfSense WAN using the good old DHCP will obtain a 192.168.1.y/24 IP.
This means you can not use 192.168.1.1/24 on the pfSense LAN !
Two options :
Change the pfSense LAN settings, like for example 192.168.2.1/24 - and the check pfSense DHCP LAN server side also (open the page, and hit Save).
Or
Change the Draytek LAN settings to use, for example, dono : 192.168.10.1/24 - so now the pfSense WAN IP will be 192.168.10.z/24 and you can keep the pfSense LAN default settings.@diyhouse said in WAN periodically Rebooting,.. Take Two:
I may even look at fibre (FTTP) as an option
Fiber can't be an option.
Normally, its fiber, and the rest is "optional". -
@Gertjan
Sorry,.. for my lack of clarity,.. when I transferred to the Draytek router config,.. PfSense was ( out of the picture,.. ie not connected ),.. I dutifully created the Draytek with the same ip as PfSense,.. ( PfSense not connected , so no conflict ) and created everything else as per my PfSense config,.. ( yes a real pain for the Binds I had in PfSense )...
The crucial thing here is as per previous correspondence is the Draytek is no better at maintaining an internet connection than Pfsense is,.. ( in fact its probably worse, as it does not reconnect very intelligently)...
So hence I am still at the drawing board... -
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.
-
@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.
-
@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.. -
-
@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
). -
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) ?
-
@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. -
Ok, thanks.
I'm amazed : plain copper (POTS ?) wires, non twisted, not shielded, and its possible to pump 70 Mbits over them ... -
@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. -
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!
-
@stephenw10
login-to-view
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...
login-to-view -
@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. -
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.
-
@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. -
@diyhouse Until the next thunderstorm.
-
@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.