Looks like my problem is back with a vengeance - REIN / SHINE

[#1]

Hi @adbeasley, we're still awaiting an update on the REIN case, I'll keep chasing this for you.

[#2]

No report from dear old OR yet.

No real difference in SNR before the drops and I'm still struggling to get the OID info from Draytek (who keep sending me the same note each time I ask)...

Drop pattern has changed - no drops on the 12th or 17th and a change in times yesterday:

Dec 14 02:26:18 192.168.1.1 DrayTek: WAN 1 is down.
Dec 14 02:28:03 192.168.1.1 DrayTek: WAN 1 is up.
Dec 15 01:34:03 192.168.1.1 DrayTek: WAN 1 is down.
Dec 15 01:35:46 192.168.1.1 DrayTek: WAN 1 is up.
Dec 16 02:09:51 192.168.1.1 DrayTek: WAN 1 is down.
Dec 16 02:11:40 192.168.1.1 DrayTek: WAN 1 is up.
Dec 16 04:51:56 192.168.1.1 DrayTek: WAN 1 is down.
Dec 16 04:53:43 192.168.1.1 DrayTek: WAN 1 is up.
Dec 18 02:35:01 192.168.1.1 DrayTek: WAN 1 is down.
Dec 18 02:36:47 192.168.1.1 DrayTek: WAN 1 is up.
Dec 19 12:55:21 192.168.1.1 DrayTek: WAN 1 is down.
Dec 19 13:01:04 192.168.1.1 DrayTek: WAN 1 is up.
Dec 19 15:08:29 192.168.1.1 DrayTek: WAN 1 is down.
Dec 19 15:10:31 192.168.1.1 DrayTek: WAN 1 is up.
Dec 19 15:21:38 192.168.1.1 DrayTek: WAN 1 is down.
Dec 19 15:23:50 192.168.1.1 DrayTek: WAN 1 is up.

Be interesting to see what happens now its warm here and the kids are off school...

[#3]

Hi Andrew, I'm sorry to see things have got worse with your connection. I'm still awaiting an update on the REIN case with Openreach, if there's no response to that by the 22nd it will be automatically escalated and I'll be able to chase it further at that point for you.

[#4]

Well Happy New Year folks.

Still waiting for OR to respond - for some reason the PN contact at OR cannot reach the team - despite then being a communications company with mobile(s) / email / call tracking systems / escalation processes etc and TBH I think this is not going to get solved - OR has no competition in the area and last time I gave up as they did not respond...

I'm 80% convinced that it's someone heating - no drops over the last week or so till tonight:

Dec 23 06:43:36 192.168.1.1 DrayTek: WAN 1 is down.
Dec 23 06:45:19 192.168.1.1 DrayTek: WAN 1 is up.
Dec 25 01:25:48 192.168.1.1 DrayTek: WAN 1 is down.
Dec 25 01:28:03 192.168.1.1 DrayTek: WAN 1 is up.
Jan  3 01:03:20 192.168.1.1 DrayTek: WAN 1 is down.
Jan  3 01:07:12 192.168.1.1 DrayTek: WAN 1 is up.

And tonight the temperature drops to close on freezing and it starts again... It's possible someone has been on holiday but I've not knocked on doors to find out (an OR trainee could do that rather than do make work ).

We are due an MP surgery soon (and a Parish Council meeting Feb) - I'm going to ask for the matter to be raised as part of these if not fixed as this has now been going on for three years!

I also need to find out how to escalate this in Plus Net as the chase is proving totally ineffective (22nd was when OR was due to escalate it).

I've also stopped tracking the SNR beyond the basic stats the router kicks out. The data just shows it sits around 15-19 at my end (can be stable for hours) and still gets killed - it's about time OR / Plus Net put their own monitors on if they need it!

Contract is up soon - should I move or stay???

[#5]

Choose which ever ISP you want, it will not change the physics of your locality, nor the ability of the local BTOR engineers to investigate the issue. Even if they were to identify the source of the REIN they have no power to force rectification.

As for monitoring it is the variation, the shape and time of it which you need to make your case.

[#6]

---

@Townman wrote:
Choose which ever ISP you want, it will not change the physics of your locality, nor the ability of the local BTOR engineers to investigate the issue. ...

---

Good points and I'm going to be back to square one with a new Helpdesk (and at least Adam helps and understands the issue).

OR failed to respond to the 2nd and 3rd level escalation but we finally got a response on the fourth level!

They are now saying this is not a REIN issue (despite saying it is twice) and its a distance problem.

I do not have the actual distance from the exchange or green cabinet (we are supposed to be fibre to the village then copper) but aa.net.uk gives me 1827m from the cabinet (E1) - interestingly, our old house (also on Plusnet but not suffering these issues) is 1774m from E1 but that line is rated at 74Mb/s compared to my lowly 51Mb/s.

I've spoken with a friend at the other side of the village who has had a few drops over the last couple of months (less than five that he knows about) and one lady who my wife works with was having lots of issues last year. Both of these are with different ISPs though so I'm a bit stuck linking their calls but both may let me put a monitor on their network.

The only alternative cabling option (other than Starlink) is KCOM who are running fibre into the major town close by BUT currently bypassing the five smaller villages between towns... I have an outstanding question why this is so with the borough council leader (under his 'ward councillor' hat TBH) but he's not replied during the last two surgeries that have been held in the villages. Interestingly, I have no idea what address database KCOM are using but they only have three houses in the dropdown for our road and I wonder if they think we are smaller than we actually are? Need to dig up the Post Code map and have a check I think...

Locally the PCs have been looking at the transport issues we have (there are real drawbacks living in rural UK) but I've volunteered to help them with the next step of that to see if I can get them to clear some time for my broadband issues next meeting.

Next step is for PN to find the actual distance and me to find historic drops (pre PN) if I still have those records as I know we have had months in a row with no drops.

I wonder if dropping the speed would increase the stability? We are only pulling 20Mb/s at peak from what I can tell so can easily drop a few Mb/s without seeing an impact I think.

[#7]

Well I'm not seeing any significant change in the SNR at this range - other than at the drop times the variation in SNR is a max of 4db (±2 basically).

Even the times of the drops are all over (grouped by 1/4 hour blocks Mon - Sun):

Adam (from PlusNet) is still pushing back on OR but they are not the fastest of responders 😞

I've dropped a note to the parish council but they do not meet for a couple of weeks and I am unsure if they have finished the transport issue from October yet (that survey response was due back start of Jan) but we will see.

Anyone else any ideas?

[#8]

You cannot look at SNRM in total isolation from other factors. What needs profiling here is the SNRM IMMEDIATELY BEFORE the drops and the speed either side of the drops.

Clusters of when they happen has limited value.

I will take another look at that cluster-plot when I return to my desk computer. In the meantime, do you have any 10 second (or finer) SNRM plots before and after a disconnection please?

[#9]

Unfortunately I only have the 27 second system log running at the moment as things where packed away due to the issues it was causing my mental health 😞

This mornings drop looks like:

Jan 24 05:40:41 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:41:07 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:41:34 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:42:01 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:42:28 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:42:55 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:43:21 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:43:48 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:44:15 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:44:42 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:45:08 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:45:35 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:45:36 192.168.1.1 DrayTek: statistic: WAN1: Tx 16 Kbps, Rx 163 Kbps (5 min average)
Jan 24 05:45:36 192.168.1.1 DrayTek: statistic: Session Usage: 105 (5 min average)
Jan 24 05:46:02 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:46:29 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:46:56 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:47:22 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:47:49 192.168.1.1 DrayTek: ADSL_Status:[Mode=17A States=SHOWTIME UpSpeed=9980000 DownSpeed=33479000 SNR=15 Atten=22 ]
Jan 24 05:48:13 192.168.1.1 DrayTek: PPP Closed : Remote Terminating (PPPoA)
Jan 24 05:48:13 192.168.1.1 DrayTek: WAN1 PPPoE ==> Protocol:LCP(c021) TermReq Identifier:0xFF ##
Jan 24 05:48:13 192.168.1.1 DrayTek: WAN 1 is down.
Jan 24 05:48:13 192.168.1.1 DrayTek: [WEB]Dynamic DNS Setup> Force Update
Jan 24 05:48:13 192.168.1.1 DrayTek: Delete exist flowstate of VPN ifno: 3 ....
Jan 24 05:48:13 192.168.1.1 DrayTek: ADSL_Status:[Mode=----- States=RESET UpSpeed=0 DownSpeed=0 SNR=0 Atten=0 ]
Jan 24 05:48:13 192.168.1.1 DrayTek: DSL: Modem Shut Down from ADSL Phy Layer (0)
Jan 24 05:49:37 192.168.1.1 DrayTek: WAN1 PPPoE ==> V:1 T:1 PADT ID:5635
Jan 24 05:49:37 192.168.1.1 DrayTek: WAN1 PPPoE --> send PADT to reset the out-of-order session.
Jan 24 05:49:38 192.168.1.1 DrayTek: WAN1 PPPoE ==> V:1 T:1 PADT ID:5635
Jan 24 05:49:38 192.168.1.1 DrayTek: WAN1 PPPoE --> send PADT to reset the out-of-order session.
Jan 24 05:49:40 192.168.1.1 DrayTek: WAN1 PPPoE ==> V:1 T:1 PADT ID:5635
Jan 24 05:49:40 192.168.1.1 DrayTek: WAN1 PPPoE --> send PADT to reset the out-of-order session.
Jan 24 05:49:40 192.168.1.1 DrayTek: WAN1 PPPoE <== V:1 T:1 PADT ID:5635
Jan 24 05:49:41 192.168.1.1 DrayTek: WAN1 PPPoE ==> V:1 T:1 PADT ID:5635
Jan 24 05:49:41 192.168.1.1 DrayTek: WAN1 PPPoE ==> V:1 T:1 PADI ID:0
Jan 24 05:49:47 192.168.1.1 DrayTek: WAN1 PPPoE ==> V:1 T:1 PADT ID:0
Jan 24 05:49:59 192.168.1.1 DrayTek: WAN1 PPPoE ==> V:1 T:1 PADT ID:0
Jan 24 05:50:02 192.168.1.1 DrayTek: WAN1 PPPoE <== V:1 T:1 PADO ID:0
Jan 24 05:50:02 192.168.1.1 DrayTek: WAN1 PPPoE ==> V:1 T:1 PADR ID:0
Jan 24 05:50:02 192.168.1.1 DrayTek: WAN1 PPPoE <== V:1 T:1 PADS ID:7309
Jan 24 05:50:02 192.168.1.1 DrayTek: PPP Start (PPPoA)

So it was sat at near end SNR of 15 and then splat - gone.

Oddly enough today we had no web access from around 06:45 through to 11:10 ish though ping would work. Had to reset the link to get anything through...

[#10]

Well the SNR ha now dropped to around 12.

I was helping with some SNMP issues overnight so knocked together a 10 second monitor and it shows:

2023-01-29T07:58:08.097Z,12
2023-01-29T07:58:18.097Z,12
2023-01-29T07:58:28.101Z,12
2023-01-29T07:58:38.106Z,12
2023-01-29T07:58:48.105Z,12
2023-01-29T07:58:58.111Z,12
2023-01-29T07:59:08.112Z,12
2023-01-29T07:59:18.112Z,0
2023-01-29T07:59:28.118Z,0
2023-01-29T07:59:38.121Z,0
2023-01-29T07:59:48.121Z,0
2023-01-29T07:59:58.127Z,0
2023-01-29T08:00:08.132Z,0
2023-01-29T08:00:18.132Z,0
2023-01-29T08:00:28.137Z,0
2023-01-29T08:00:38.142Z,0
2023-01-29T08:00:48.141Z,12
2023-01-29T08:00:58.147Z,12

So its not slowly dropping just dropping...

I've put the file up on Pastebin https://pastebin.com/gAFsuTYu - I can see the odd 13 and 9 and can run the log again in a day or so for a longer period.

[#11]

Does RouterStats work with this router?

That drop looked like a clean break - any thoughts on what caused the drop?  -12dB is a sizable spike!

Is the phone line still quiet?

I think that this is worth raising a fault report for.

[#12]

RouterStats are an issue for me as I do not use Windows and my only Linux boxes here at the mo are ARM machines (Pi) and I failed to get it running last time on these (WINE + QEMU) and the loan PC was not good! 

They seem to use the same interface (SNMP) to pull the data from the router (they may compatible as the Draytek 2600 range is and mine is a 2700) as I do so is it just the graphing aspect you would like to see?

-12dB is not the largest I have seen, the router has been reporting drops from an SNR of 15 and 19 before today!

Voice is fine - quiet line test shows nothing (though I have not tried it during a drop recently) but dial-tone exists ever time I try. I must write the test number down as I have a habit of going to the 'net to look it up and then cursing myself 🙂

As for the call - one (229472591) has been open since the end of November but no update in the last week (despite chasing twice). I think my contact has been off and no one else can get into his mail (shock) as he was waiting an update from OR who are currently blaming line length (though they cannot seem to agree on the actual length).

[#13]

Hi Andrew, hoping all is well with you. I've been away from work ill since last week but back at it today so please bear with me and I'll get things chased up and come back to you with an update a little later. 

[#14]

Shame that Linux is so unfriendly and that what works universally elsewhere needs so much effort to be hand crafted.  A poke around the internet found this - Monitoring a DrayTek router with collectd and Grafana | Linux Things  - which just might be of interest to you!

[#15]

@Townman Thank you for that link - I've not seen collectd so I've a new plaything 🙂 I did find this post from BG Go Further about capturing the syslog data with the program rather than reading it as a file.

Still not getting anywhere with OR and line length - it's being escalated but not holding my breath... The cold weather seemed to increase the drops though I've only had 5 this month so far. One drop was very odd - I could ping any site and had a stable connection BUT no web site would load. Took a reboot to allow web traffic again. I forgot to do a ping with increasing packet size to see what the cut off packet size was but this is the second time I've seen this here. Only came across this once before on an industrial estate where the copper circuits where over-committed and I needed 'Group IT' to get involved with C&W who provided the companies data to work with OR to provision something useable (we where an international logistic company and I was at divisional level).

OR had three vans out in the village today but no idea who / why.

Turns out the stats screen on the Draytek GUI has a bug and it randomly reboots the router. The RC1 fix I was asked to test did not help so the temporary fix from them is to remove the functionality while they work on it! Fortunately, SNMP does not cause a reboot (though the plumber nearly did).

The use of telnet is not my favourite as passwords are sent in plain text over the LAN (though that's a low risk TBH) but the box supports ssh as long as you have the correct encryption type loaded - so in my case my ssh config has:

Host 192.168.1.1
  KexAlgorithms +diffie-hellman-group1-sha1

to enable this access.

I can then run the vdsl status command (documented on the Draytek site here) as per the Linux Things article but over a secure link 🙂

This is still slower and higher CPU than the SNMP get and subject to possible layout changes in future firmware whereas SNMP is traditionally more stable for monitoring.

I've been trying to get a basic Linux (x86 codebase) running under UTM on my M1 iMac - horrendous result so far with basic speed tests return results slightly slower than a Pi 4B so Windows on this box is out! Hopefully with the next stage of the house repairs coming to a close (fingers crossed - we have only had two water leaks through the ceiling in the last three weeks) I'll be able to spend some more time on this monitoring and may be able to get a spare network port up and running for a 'real' PC.