In reply to a post by caffn8me:

In reply to a post by Zarjaz:

I don’t know Tim .... it seems a very random/unusual fault.

I suppose, if pushed for a guess, now you have had a lift and shift done (that is what is implied by recent posts isn’t it ?) I would probably agree.

Will your service provider strip out and then rebuild your account on their home gateway ?

I had a lift and shift done at a site and it didn't improve matters. Another visit some time later and the engineer fixed it by moving to a port on a different line card in the cabinet.

That's what I have been told has been done Sarah.

PPP dropped 23:28 and my speed is back to normal. Something seriously wrong with the Uno gateway/network.

Another drop under load at 3:42. This time it was short enough for streaming to continue and the download to resume.

Pretty picture

And here's the router log excerpt of the drop.

2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0xe5]
2020-09-10 03:40:59 [3] PPP: ppp1 LCP down
2020-09-10 03:40:59 [4] PPP: ppp1 LCP down
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0xe5]
2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0x1]
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0x1]
2020-09-10 03:41:02 [3] PPP: ppp1
2020-09-10 03:41:18 [6] PPP: ppp1 sent [PADI Host-Uniq(0x00000bc5)]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [LCP ConfReq id=0x1 <mru 1480> <magic 0xc0cb005>]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [LCP ConfReq id=0x29 <auth chap MD5> <magic 0x6bd5ee51>]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [LCP ConfAck id=0x29 <auth chap MD5> <magic 0x6bd5ee51>]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [LCP ConfAck id=0x1 <mru 1480> <magic 0xc0cb005>]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [LCP EchoReq id=0x0 magic=0xc0cb005]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [CHAP Challenge id=0x10 <c07f00025cc1c4a6f7c8f3f9dd48>, name = "nge001.new"]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [CHAP Response id=0x10 <b2e044e94794f1ea245d04187e6714c8>, name = "[email protected]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [LCP EchoRep id=0x0 magic=0x6bd5ee51]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [CHAP Success id=0x10 ""]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [IPCP ConfReq id=0x1 <addr xx.xx.136.48>]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [IPCP ConfAck id=0x1 <addr xx.xx.136.48>]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [IPV6CP ConfReq id=0x1 <addr fe80::76a2:e6ff:fe4f:e400>]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [LCP ProtRej id=0x2 80 57 01 01 00 0e 01 0a 76 a2 e6 ff fe 4f e4 00]

Edited by Banger (Thu 10-Sep-20 03:53:48)

That looks like huge loss of ping responses. There does not appear to be any loss of PPP. Similarly, no way could streaming continue if the line "dropped".

I think you may be looking for the wrong thing. Asking the wrong question. Reporting the the wrong problem to your provider.

Edit: Looking further, assuming this happened not long before you posted it, your live BQM shows no huge problem, just an episode of dropped pings at the time, also 11:30pm and 7am. I've never heard of drop-netmeter, but which interface(s) is it monitoring?

Edit 2: I was also misunderstanding the "pretty picture". The red portions appear to be normal download periods? With a very low level of green uploads at the end.

Edited by RobertoS (Thu 10-Sep-20 10:43:42)

In reply to a post by RobertoS:

There does not appear to be any loss of PPP.

I see this log section:

2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0xe5]
2020-09-10 03:40:59 [3] PPP: ppp1 LCP down
2020-09-10 03:40:59 [4] PPP: ppp1 LCP down
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0xe5]
2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0x1]
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0x1]
2020-09-10 03:41:02 [3] PPP: ppp1

LCP (Link Control Protcol) being down usually means the connetion is down. The TermReq implies something remote (ISP end?) requested termination of the link. I don't know if the ID 0xe5 is a reason code, but Juniper has a reference here.

On a BT router log, I've seen 0x2 and 0x3 say "user request", but I can't seem to find 0xe5. I believe E5 in hex would be 229 in decimal, a significantly higher number than 2 or 3, so I wonder if it a vendor specific code from the remote end.

Edited by jchamier (Thu 10-Sep-20 11:01:01)

"Usually" being important in the context, particularly this one. AIUI LCP requires an initial PPP connection in order to get the link properly set up. That I presume is what the ppp1 is.

Did you see my final version, following a few edits? Tim's BQM shows dropped pings, but not much else in terms of significant problems.

In reply to a post by jchamier:

In reply to a post by RobertoS:

There does not appear to be any loss of PPP.

I see this log section:

2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0xe5]
2020-09-10 03:40:59 [3] PPP: ppp1 LCP down
2020-09-10 03:40:59 [4] PPP: ppp1 LCP down
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0xe5]
2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0x1]
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0x1]
2020-09-10 03:41:02 [3] PPP: ppp1

LCP (Link Control Protcol) being down usually means the connetion is down. The TermReq implies something remote (ISP end?) requested termination of the link. I don't know if the ID 0xe5 is a reason code, but Juniper has a reference here.

On a BT router log, I've seen 0x2 and 0x3 say "user request", but I can't seem to find 0xe5. I believe E5 in hex would be 229 in decimal, a significantly higher number than 2 or 3, so I wonder if it a vendor specific code from the remote end.

Uno session history used to show these reasons. Interesting that the TermReqd comes before the LCP down. Now they have hidden them and I bet 229 is port error which used to show up when the LCP dropped.

In reply to a post by jchamier:

In reply to a post by RobertoS:

There does not appear to be any loss of PPP.

I see this log section:

2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0xe5]
2020-09-10 03:40:59 [3] PPP: ppp1 LCP down
2020-09-10 03:40:59 [4] PPP: ppp1 LCP down
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0xe5]
2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0x1]
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0x1]
2020-09-10 03:41:02 [3] PPP: ppp1

LCP (Link Control Protcol) being down usually means the connetion is down. The TermReq implies something remote (ISP end?) requested termination of the link. I don't know if the ID 0xe5 is a reason code, but Juniper has a reference here.

On a BT router log, I've seen 0x2 and 0x3 say "user request", but I can't seem to find 0xe5. I believe E5 in hex would be 229 in decimal, a significantly higher number than 2 or 3, so I wonder if it a vendor specific code from the remote end.

Further reading lead me to this https://www.juniper.net/documentation/en_US/junos/to... where 5 decimal is "session timeout".

In reply to a post by RobertoS:

That looks like huge loss of ping responses. There does not appear to be any loss of PPP. Similarly, no way could streaming continue if the line "dropped".

I think you may be looking for the wrong thing. Asking the wrong question. Reporting the the wrong problem to your provider.

Edit: Looking further, assuming this happened not long before you posted it, your live BQM shows no huge problem, just an episode of dropped pings at the time, also 11:30pm and 7am. I've never heard of drop-netmeter, but which interface(s) is it monitoring?

Edit 2: I was also misunderstanding the "pretty picture". The red portions appear to be normal download periods? With a very low level of green uploads at the end.

Netmeter monitors traffic on my PC which does the automated tests, it monitors the NIC on my PC. You are correct they are non spikey after a PPP drop and new session. The green is local LAN traffic of which cause I forget now but it is between Windows PCs.

In reply to a post by RobertoS:

"Usually" being important in the context, particularly this one. AIUI LCP requires an initial PPP connection in order to get the link properly set up. That I presume is what the ppp1 is.

ppp1 is the virtual (software) network card that the PPP client creates, and which is assigned the IP when connected. I remember this from dial up internet connections in the early 1990s where you dialled, and then created a ppp link. LCP is the protocol that actually _creates_ the ppp link, it is the "link control protocol".

Did you see my final version, following a few edits? Tim's BQM shows dropped pings, but not much else in terms of significant problems.

The BQM can't see this layer, once there is a drop (ISP end or user end) the TCP address is gone, so nothing for BQM to ping.