I will also change to dynamic IP on the WAN2 next visit

After talking to someone on the plusnet forum I eventually managed to open the syslog .DB files that I retrieved from my NAS and found a termination sequence that coincides with me losing contact with the router.  following is a copy of the post to Plusnet forumI trawled through 3 days of logs where nothing much was happening except LCP EchoReq and EchoRep until the point where it appears the router chooses to close the connection.  No indication of why that I can see.  Here is the last part of that log hope it posts ok... (There are IPv6 requests in this log, I've turned IPv6 off now but they were going on in this log file for 3 days so I dont think they are significant in the reasons for the termination)2024-08-2413:01:28DrayTekWAN2 PPPoE <== Protocol:LCP(c021) EchoReq Identifier:0x6E Magic Number: 0x2a79 5c 40 ##2024-08-2413:01:28DrayTekWAN2 PPPoE ==> Protocol:LCP(c021) EchoRep Identifier:0x6E Magic Number: 0x0 00 00 ##2024-08-2413:01:29DrayTekWAN2 PPPoE ==> Protocol:LCP(c021) TermReq Identifier:0x23 ##2024-08-2413:01:30DrayTekWAN2 PPPoE ==> Protocol:IPv6CP(8057) ConfReq Identifier:0x06 Interface Identifier: 00 1d aa ff fe 66 62 ba ##2024-08-2413:01:31DrayTekWAN2 PPPoE ==> Protocol:LCP(c021) TermReq Identifier:0x24 ##2024-08-2413:01:33DrayTekWAN2 PPPoE ==> Protocol:IPv6CP(8057) ConfReq Identifier:0x07 Interface Identifier: 00 1d aa ff fe 66 62 ba ##2024-08-2413:01:34DrayTekWAN2 PPPoE ==> Protocol:LCP(c021) TermReq Identifier:0x25 ##2024-08-2413:01:35DrayTekWAN2 PPPoE <== Protocol:LCP(c021) TermAck Identifier:0x25 ##
I can't see any reason for the Draytek to initiate the termination.

That obviously didnt post well, and I realised later was filtered.  attached is a more detailed log
1724500887    1724500888    +01:00    2024-08-24    13:01:27    DrayTek    [QoS] -2 VoIP calls detected... Adjust bandwidth allocation.
1724500887    1724500888    +01:00    2024-08-24    13:01:27    DrayTek    WAN2 PPPoE ==> Protocol:IPv6CP(8057) ConfReq Identifier:0x05  Interface Identifier: 00 1d aa ff fe 66 62 ba ##
1724500888    1724500888    +01:00    2024-08-24    13:01:28    DrayTek    WAN2 PPPoE <== Protocol:LCP(c021) EchoReq Identifier:0x6E Magic Number: 0x2a79 5c 40 ##
1724500888    1724500888    +01:00    2024-08-24    13:01:28    DrayTek    WAN2 PPPoE ==> Protocol:LCP(c021) EchoRep Identifier:0x6E Magic Number: 0x0 00 00 ##
1724500889    1724500889    +01:00    2024-08-24    13:01:29    DrayTek    PPP Closed : No Echo Response (PPPoE)
1724500889    1724500889    +01:00    2024-08-24    13:01:29    DrayTek    WAN2 PPPoE ==> Protocol:LCP(c021) TermReq Identifier:0x23  ##
1724500889    1724500890    +01:00    2024-08-24    13:01:29    DrayTek    PPP Closed : No Echo Response (PPPoE)
1724500890    1724500890    +01:00    2024-08-24    13:01:30    DrayTek    PPP Closed : No Echo Response (PPPoE)
1724500890    1724500891    +01:00    2024-08-24    13:01:30    DrayTek    PPP Closed : No Echo Response (PPPoE)
1724500890    1724500891    +01:00    2024-08-24    13:01:30    DrayTek    WAN2 PPPoE ==> Protocol:IPv6CP(8057) ConfReq Identifier:0x06  Interface Identifier: 00 1d aa ff fe 66 62 ba ##
1724500891    1724500891    +01:00    2024-08-24    13:01:31    DrayTek    PPP Closed : No Echo Response (PPPoE)
1724500891    1724500892    +01:00    2024-08-24    13:01:31    DrayTek    PPP Closed : No Echo Response (PPPoE)
1724500891    1724500892    +01:00    2024-08-24    13:01:31    DrayTek    WAN2 PPPoE ==> Protocol:LCP(c021) TermReq Identifier:0x24  ##
1724500892    1724500892    +01:00    2024-08-24    13:01:32    DrayTek    PPP Closed : No Echo Response (PPPoE)
1724500892    1724500893    +01:00    2024-08-24    13:01:32    DrayTek    PPP Closed : No Echo Response (PPPoE)
1724500892    1724500893    +01:00    2024-08-24    13:01:32    DrayTek    [QoS] -2 VoIP calls detected... Adjust bandwidth allocation.
1724500893    1724500893    +01:00    2024-08-24    13:01:33    DrayTek    PPP Closed : No Echo Response (PPPoE)
1724500893    1724500894    +01:00    2024-08-24    13:01:33    DrayTek    PPP Closed : No Echo Response (PPPoE)
1724500893    1724500894    +01:00    2024-08-24    13:01:33    DrayTek    WAN2 PPPoE ==> Protocol:IPv6CP(8057) ConfReq Identifier:0x07  Interface Identifier: 00 1d aa ff fe 66 62 ba ##
1724500894    1724500894    +01:00    2024-08-24    13:01:34    DrayTek    PPP Closed : No Echo Response (PPPoE)
1724500894    1724500895    +01:00    2024-08-24    13:01:34    DrayTek    PPP Closed : No Echo Response (PPPoE)
1724500894    1724500895    +01:00    2024-08-24    13:01:34    DrayTek    WAN2 PPPoE ==> Protocol:LCP(c021) TermReq Identifier:0x25  ##
1724500895    1724500895    +01:00    2024-08-24    13:01:35    DrayTek    WAN2 PPPoE <== Protocol:LCP(c021) TermAck Identifier:0x25  ##
1724500895    1724500895    +01:00    2024-08-24    13:01:35    DrayTek    WAN 2 is down.
1724500895    1724500895    +01:00    2024-08-24    13:01:35    DrayTek    [WEB]Dynamic DNS Setup> Force Update
1724500895    1724500895    +01:00    2024-08-24    13:01:35    DrayTek    Delete exist flowstate of VPN ifno: 4 ....
1724500895    1724500895    +01:00    2024-08-24    13:01:35    DrayTek    =====DDNS UPDATED FAILED(synds918):WAN IP not present=====
1724500895    1724500896    +01:00    2024-08-24    13:01:35    DrayTek    Local User (MAC=EC-74-D7-1B-D2-A5): 192.168.1.11:58806 -> 81.187.30.115:3478 (UDP)

 

Steve, I think you stand a better chance of getting an interpretation of the PPPoE logs on the Plusnet forum.

I wonder if the first line (apparently a VoIP call coming in) has some significance although as it would just go to your Grandstream (with it's own PSU I assume).

I might also slightly wonder about earthing and however the Grandstream generates the ringing voltage.

Also whatever "consumes" the phone connection (I assume a "normal" phone).

The thinkbroadband monitor has a couple of points of mild interest.

Someone (Openreach/Plusnet?) did a couple of reboots of something overnight (the 2 red spikes a bit after 1am are suggestive of a reboot somewhere).

Another packet loss event (probably coinciding with some use of the connection) seems to have happened at 2pm.

Then something made the maximum latency increase a bit before the link went down at 5:10pm.

This kind of fault finding can be quite tricky. Speculating, if something upset the physical WAN connection then the PPPoE session would fail.

Hence my wonder about power supply.

To get Plusnet to involve Openreach you would need to reproduce this with Plusnet's router in circuit (and you would need logs so not in bridge mode).

You could try putting the Plusnet router in the circuit (in its normal mode) and the Draytek WAN connection as DHCP. To get VPN access you would need to use the VPN matcher service as you would be behind NAT. It's all quite a "faff" but I can't think of another way.

markhawkin wrote:

You could try putting the Plusnet router in the circuit (in its normal mode) and the Draytek WAN connection as DHCP. To get VPN access you would need to use the VPN matcher service as you would be behind NAT. It's all quite a "faff" but I can't think of another way.

…you could always set the Plusnet router to DMZ directly to the DHCP’d (NAT’d) Draytek router, this has worked for me in the past and will allow VPN through directly, without using the Matcher service.

Thanks to both HodgesanDY and markhawkin for your suggestions, they sound like a good way to go on my next visit.  I have posted the logs on plusnet and await someones kind interest there.  Regarding the 1am glitch, I did try to make the router reboot at about 1am on a schedule so that may be the cause of that, my thinking was if it lost connection a reboot might trigger a reconnection and I could retrieve logs and continue working.  I hoped that the scheduling would be on a day-by-day basis so that I could reboot at 1am forevermore but I don't think it works like that somehow, all I can hope for is a week of reboots.  I did wonder if the VoIP detection might have changed things in some way and triggered a downgrade of something that resulted in loss of the line.  I don't think the Grandstream (how did you know I had that, did I say earlier or did you glean it from the logs?) ring voltage should cause any problems as it and the router are connected only by ethernet cables which are balanced and transformer coupled so shouldn't be able to interfere but you never know.  Maybe next time I get it up and running again I should test with an incoming voip call and see what happens.  I thought I had all QOS turned off but maybe there is some part of it that you can't turn off - one of the problems with Draytek is there is so much stuff to set up, which is also its strength.
Thinking about upsetting the physical WAN connection - when I replaced the cable last, swapping the one supplied with the plusnet HUB2 for a new Cat6a, I did notice the ONT was moveable and wondered if that might disturb the fibre connection sufficiently to disrupt things, but I would expect that would manifest in the PON light changing (either to off or a different colour) rather than the LAN light.  I agree about the trickiness of this kind of fault finding, I spent my working life writing code (actually mostly for System-X exchanges that are being ripped out as people like me move to fibre and voip) and finding obscure intermittent faults, so I know how frustrating and difficult it can be and that is why I appreciate everyone's insight as each new idea gives me a different angle on the problem and a different way of tracking it down, so thanks again to everyone who has/will contribute!