Kitz Forum
Broadband Related => ADSL Issues => Topic started by: DiggerOfHoles on May 03, 2019, 04:50:49 PM
-
Hello all,
I'm new to this forum thing and for once I've read the rules.
Can anyone tell me if I barking mad or barking up the correct tree.
In respect of the rules I am posting a link to community BT and I am also lazy.
https://community.bt.com/t5/ADSL-Copper-broadband/PPP-Dropouts-during-day-remote-station-is-not-answering-to-LCP/td-p/1940705/page/3
Page 3 is my question. Save you a read.
If a mod says it's OK I can edit and transfer here.
I will try to behave my self BT don't half push my ,spit, retail buttons.
Thanks for looking.
Any one up for a game of pin the tail on the donkey.
-
I got the impression that most of the logs in that thread did contain a retrain of the DSL layer, therefore I have no idea why you seem to be focussing on other aspects.
-
The line is in retrain but still PPP dropping connection not sync due to non answered echo requests.
-
I was just saying retrain as the proper term for resync.
It's not surprising that LCP echo requests won't get answered when the underlying DSL link is down.
-
Note the time difference where arrow is. Some time after retrain?
Sorry talking BT speak.
-
I think there's a time difference between those log entries where the arrow is because nothing has happened (or at least nothing logged) between 14:05 Apr 24 and 11:06 Apr 25. It's so far after the last retrain that it's at the next retrain!
14:05 Apr 24 DSL goes down.
11:10 Apr 25 DSL goes down and perhaps it was effectively down (unusable) around 11:06. I think the most likely explanation for the log entries from 11:06 to 11:10 is that whatever caused the DSL to drop was also affecting the quality of the DSL link for a few minutes before it took it out completely.
Can anyone tell me if I barking mad or barking up the correct tree.
Yes and no, respectively.
-
That's my line of thinking but I have no SNR observation to prove it.
The symptom is a congested times of the day the net will go slower and slower.
Normally I would expect it to speed up eventually.
What I am getting at these times is a new IP address with no retrain.
Or no IP and a retrain some minutes later.
Note BT HUB 4B ADSL(0) Max not 2+
00:54:31, 02 Apr. NTP synchronization success
00:54:18, 02 Apr. NTP synchronization start
00:54:16, 02 Apr. WAN connection ATM connected
00:54:16, 02 Apr. PPP IPCP Receive Configuration ACK
00:54:16, 02 Apr. PPP IPCP Send Configuration Request
00:54:16, 02 Apr. PPP IPCP Receive Configuration NAK
00:54:16, 02 Apr. PPP IPCP Send Configuration Request
00:54:15, 02 Apr. PPP IPCP Receive Configuration Reject
00:54:15, 02 Apr. PPP IPCP Send Configuration ACK
00:54:15, 02 Apr. PPP IPCP Receive Configuration Request
00:54:15, 02 Apr. PPP IPCP Send Configuration Request
00:54:15, 02 Apr. PPP CHAP Receive success : authentication successful
00:54:15, 02 Apr. PPP CHAP Receive Challenge
00:54:14, 02 Apr. PPP LCP Send Configuration ACK
00:54:14, 02 Apr. PPP LCP Receive Configuration Request
00:54:14, 02 Apr. PPP LCP Receive Configuration ACK
00:54:14, 02 Apr. PPP LCP Send Configuration Request
00:54:12, 02 Apr. PPP LCP Receive Configuration ACK
00:54:11, 02 Apr. PPP LCP Send Configuration Request
00:54:08, 02 Apr. DSL Link Up: Down Rate=2848Kbps, Up Rate=448Kbps; SNR Margin Down=6.9dB, Up=16.0dB
00:53:34, 02 Apr. PPP LCP Send Termination Request (User request)
00:53:31, 02 Apr. PPP LCP Send Termination Request (User request)
00:53:31, 02 Apr. DSL Link Down: duration was 309552 seconds
00:53:30, 02 Apr. PPP LCP Send Configuration Request
00:53:29, 02 Apr. WAN connection ATM disconnected
00:53:21, 02 Apr. PPP LCP Send Termination Request (User request)
00:53:18, 02 Apr. PPP LCP Send Termination Request (Peer not responding)
21:17:51, 01 Apr. Receive a DHCP request
13:21:38, 01 Apr. admin login success from 192.168.1.190
As far as I can tell PPP LCP Send Termination Request (Peer not responding) means 6 contiguous echo packets sent by router to ISP HQ over backhaul have not been answered by ISP. Thus causing the router to take down the PPP session without retrain and start a new one. See below.
09:49:26, 29 Mar. NTP synchronization success
09:49:12, 29 Mar. NTP synchronization start
09:49:10, 29 Mar. WAN connection ATM connected
09:49:10, 29 Mar. PPP IPCP Receive Configuration ACK
09:49:10, 29 Mar. PPP IPCP Send Configuration Request
09:49:10, 29 Mar. PPP IPCP Receive Configuration NAK
09:49:09, 29 Mar. PPP IPCP Send Configuration Request
09:49:09, 29 Mar. PPP IPCP Receive Configuration Reject
09:49:09, 29 Mar. PPP IPCP Send Configuration ACK
09:49:09, 29 Mar. PPP IPCP Receive Configuration Request
09:49:09, 29 Mar. PPP IPCP Send Configuration Request
09:49:09, 29 Mar. PPP CHAP Receive success : authentication successful
09:49:08, 29 Mar. PPP CHAP Receive Challenge
09:49:08, 29 Mar. PPP LCP Send Configuration ACK
09:49:08, 29 Mar. PPP LCP Receive Configuration Request
09:49:08, 29 Mar. PPP LCP Receive Configuration ACK
09:49:08, 29 Mar. PPP LCP Send Configuration Request
09:49:05, 29 Mar. PPP LCP Receive Configuration ACK
09:49:04, 29 Mar. PPP LCP Send Configuration Request
09:49:01, 29 Mar. DSL Link Up: Down Rate=2112Kbps, Up Rate=448Kbps; SNR Margin Down=6.6dB, Up=15.0dB
09:48:23, 29 Mar. PPP LCP Send Termination Request (User request)
09:48:20, 29 Mar. PPP LCP Send Termination Request (User request)
09:48:19, 29 Mar. DSL Link Down: duration was 5344 seconds
09:48:19, 29 Mar. Restart Button Release
09:48:17, 29 Mar. PPP LCP Send Configuration Request
09:48:15, 29 Mar. Restart Button Press
09:48:14, 29 Mar. PPP LCP Send Configuration Request
09:48:13, 29 Mar. Restart Button Release
09:48:12, 29 Mar. Restart Button Press
09:48:11, 29 Mar. PPP LCP Send Configuration Request
09:48:08, 29 Mar. PPP LCP Send Configuration Request
09:47:34, 29 Mar. PPP LCP Send Configuration Request
09:47:31, 29 Mar. PPP LCP Send Configuration Request
09:47:28, 29 Mar. PPP LCP Send Configuration Request
09:47:25, 29 Mar. PPP LCP Send Configuration Request
09:47:22, 29 Mar. PPP LCP Send Configuration Request
09:47:18, 29 Mar. PPP LCP Send Configuration Request
09:47:15, 29 Mar. PPP LCP Send Configuration Request
09:47:12, 29 Mar. PPP LCP Send Configuration Request
09:47:09, 29 Mar. PPP LCP Send Configuration Request
09:47:06, 29 Mar. PPP LCP Send Configuration Request
09:46:32, 29 Mar. PPP LCP Send Configuration Request
09:46:29, 29 Mar. PPP LCP Send Configuration Request
09:46:26, 29 Mar. PPP LCP Send Configuration Request
09:46:23, 29 Mar. PPP LCP Send Configuration Request
09:46:19, 29 Mar. PPP LCP Send Configuration Request
09:46:16, 29 Mar. PPP LCP Send Configuration Request
09:46:13, 29 Mar. PPP LCP Send Configuration Request
09:46:10, 29 Mar. PPP LCP Send Configuration Request
09:46:07, 29 Mar. PPP LCP Send Configuration Request
09:46:04, 29 Mar. PPP LCP Send Configuration Request
09:45:30, 29 Mar. PPP LCP Send Configuration Request
09:45:27, 29 Mar. PPP LCP Send Configuration Request
09:45:24, 29 Mar. PPP LCP Send Configuration Request
09:45:21, 29 Mar. PPP LCP Send Configuration Request
09:45:18, 29 Mar. PPP LCP Send Configuration Request
09:45:15, 29 Mar. PPP LCP Send Configuration Request
09:45:11, 29 Mar. PPP LCP Send Configuration Request
09:45:08, 29 Mar. PPP LCP Send Configuration Request
09:45:05, 29 Mar. PPP LCP Send Configuration Request
09:45:02, 29 Mar. PPP LCP Send Configuration Request
09:45:01, 29 Mar. WAN connection ATM disconnected
09:44:51, 29 Mar. PPP LCP Send Termination Request (User request)
09:44:48, 29 Mar. PPP LCP Send Termination Request (Peer not responding)
09:40:58, 29 Mar. admin login success from 192.168.1.190
09:21:56, 29 Mar. admin login success from 192.168.1.190
09:00:14, 29 Mar. admin login success from 192.168.1.190
08:20:31, 29 Mar. CWMP: HDM socket closed successfully.
08:20:31, 29 Mar. CWMP: HTTP authentication success from pbthdm.x.x.x
08:20:31, 29 Mar. CWMP: HDM socket opened successfully.
08:20:31, 29 Mar. CWMP: session completed successfully
08:20:31, 29 Mar. CWMP: HDM socket closed successfully.
08:20:31, 29 Mar. CWMP: HTTP authentication success from pbthdm.x.x.x
08:20:30, 29 Mar. CWMP: HDM socket opened successfully.
08:20:30, 29 Mar. CWMP: HDM socket opened successfully.
08:20:27, 29 Mar. CWMP: Server URL: https://pbthdm.x.x.x; Connecting as user: ACS username
08:20:27, 29 Mar. CWMP: Session start now, server: pbthdm.x.x.x, Event code:
08:20:27, 29 Mar. CWMP: Initializing transaction for event code 4 VALUE CHANGE
08:20:18, 29 Mar. CWMP: HDM socket closed successfully.
08:20:18, 29 Mar. CWMP: HTTP authentication success from pbthdm.x.x.x
08:20:18, 29 Mar. CWMP: HDM socket opened successfully.
08:20:17, 29 Mar. CWMP: session completed successfully
08:20:17, 29 Mar. CWMP: HDM socket closed successfully.
08:20:17, 29 Mar. CWMP: HTTP authentication success from pbthdm.x.x.x
08:20:16, 29 Mar. CWMP: HDM socket opened successfully.
08:20:16, 29 Mar. CWMP: HDM socket opened successfully.
08:20:13, 29 Mar. CWMP: Server URL: https://pbthdm.x.x.x; Connecting as user: ACS username
08:20:13, 29 Mar. CWMP: Session start now, server: pbthdm.x.x.x, Event code:
08:20:13, 29 Mar. CWMP: Initializing transaction for event code 1 BOOT
08:19:39, 29 Mar. NTP synchronization success
08:19:25, 29 Mar. NTP synchronization start
08:19:23, 29 Mar. WAN connection ATM connected
08:19:23, 29 Mar. PPP IPCP Receive Configuration ACK
08:19:23, 29 Mar. PPP IPCP Send Configuration Request
08:19:23, 29 Mar. PPP IPCP Receive Configuration NAK
08:19:22, 29 Mar. PPP IPCP Send Configuration Request
08:19:22, 29 Mar. PPP IPCP Receive Configuration Reject
08:19:22, 29 Mar. PPP IPCP Send Configuration ACK
08:19:22, 29 Mar. PPP IPCP Receive Configuration Request
08:19:22, 29 Mar. PPP IPCP Send Configuration Request
08:19:22, 29 Mar. PPP CHAP Receive success : authentication successful
08:19:22, 29 Mar. PPP CHAP Receive Challenge
08:19:21, 29 Mar. PPP LCP Receive Configuration ACK
08:19:21, 29 Mar. PPP LCP Send Configuration ACK
08:19:21, 29 Mar. PPP LCP Receive Configuration Request
08:19:21, 29 Mar. PPP LCP Send Configuration Request
08:19:18, 29 Mar. PPP LCP Receive Configuration ACK
08:19:18, 29 Mar. PPP LCP Send Configuration Request
08:19:15, 29 Mar. DSL Link Up: Down Rate=2720Kbps, Up Rate=448Kbps; SNR Margin Down=6.2dB, Up=14.0dB
08:18:43, 29 Mar. PPP LCP Send Termination Request (User request)
08:18:40, 29 Mar. PPP LCP Send Termination Request (User request)
08:18:40, 29 Mar. DSL Link Down: duration was 20 seconds
08:18:37, 29 Mar. PPP IPCP Send Configuration Request
08:18:35, 29 Mar. 2.4G WiFi auto selected channel 1 Bandwidth:20M(Reason:boot)
08:18:34, 29 Mar. PPP IPCP Send Configuration Request
08:18:32, 29 Mar. 2.4G WiFi scan(Reason:boot)
08:18:31, 29 Mar. 5G WiFi auto selected channel 48 Bandwidth:40M(Reason:boot)
08:18:31, 29 Mar. PPP IPCP Send Configuration Request
08:18:31, 29 Mar. PPP IPCP Receive Configuration Reject
08:18:30, 29 Mar. PPP IPCP Send Configuration ACK
08:18:30, 29 Mar. PPP IPCP Receive Configuration Request
08:18:30, 29 Mar. PPP IPCP Send Configuration Request
08:18:30, 29 Mar. PPP CHAP Receive success : authentication successful
08:18:30, 29 Mar. PPP CHAP Receive Challenge
08:18:30, 29 Mar. PPP LCP Send Configuration ACK
08:18:29, 29 Mar. PPP LCP Receive Configuration Request
08:18:29, 29 Mar. PPP LCP Receive Configuration ACK
08:18:29, 29 Mar. PPP LCP Send Configuration Request
08:18:26, 29 Mar. PPP LCP Receive Configuration ACK
08:18:26, 29 Mar. PPP LCP Send Configuration Request
08:18:26, 29 Mar. 5G WiFi scan(Reason:boot)
08:18:20, 29 Mar. DSL Link Up: Down Rate=2720Kbps, Up Rate=448Kbps; SNR Margin Down=6.2dB, Up=15.0dB
08:18:09, 29 Mar. 5G WiFi auto selected channel 36 Bandwidth:40M(Reason:boot)
08:18:08, 29 Mar. Booting firmware v0.07.05.03230-BT (Fri Mar 23 19:56:07 2018)
08:18:08, 29 Mar. System start Button press (PowerButton)
08:18:04, 29 Mar. Device Connected: 192.168.1.190, 60:03:47:2e:cf:b4, unknown
08:18:02, 29 Mar. 5G WiFi scan(Reason:boot)
08:18:02, 29 Mar. DHCP Lease issued 192.168.1.190 to 60:03:47:2e:cf:b4 , lease duration is 86400 seconds
08:17:58, 29 Mar. Receive a DHCP request
08:17:56, 29 Mar. Receive a DHCP request
08:17:53, 29 Mar. Receive a DHCP request
08:17:50, 29 Mar. System up
08:17:46, 29 Mar. Wire Lan Port 2 up
08:17:35, 29 Mar. 2.4G WPS feature enabled
08:17:35, 29 Mar. 2.4G WPA/WPA2 mode selected
08:17:35, 29 Mar. 2.4G WiFi DOWN
08:17:35, 29 Mar. 5G WPS feature enabled
08:17:35, 29 Mar. 5G WPA2 mode selected
08:17:35, 29 Mar. 5G WiFi DOWN
08:17:34, 29 Mar. IPv6 Service: DHCP Server stop
08:17:34, 29 Mar. IPv6 Service: RA Server stop
08:16:09, 29 Mar. PPP LCP Receive Configuration ACK
08:16:09, 29 Mar. PPP LCP Send Configuration Request
08:16:06, 29 Mar. PPP LCP Send Configuration Request
08:16:02, 29 Mar. PPP LCP Send Configuration Request
08:15:59, 29 Mar. PPP LCP Send Configuration ACK
08:15:59, 29 Mar. PPP LCP Send Configuration Request
08:15:59, 29 Mar. PPP LCP Receive Configuration Request
08:15:31, 29 Mar. PPP LCP Receive Configuration ACK
08:15:31, 29 Mar. PPP LCP Send Configuration Request
08:15:28, 29 Mar. PPP LCP Send Configuration Request
08:15:25, 29 Mar. PPP LCP Send Configuration Request
08:15:25, 29 Mar. PPP LCP Send Configuration ACK
08:15:25, 29 Mar. PPP LCP Receive Configuration Request
08:15:22, 29 Mar. PPP LCP Send Configuration Request
08:14:48, 29 Mar. PPP LCP Send Termination Request (Peer not responding)
08:14:45, 29 Mar. PPP LCP Send Termination Request (Peer not responding)
08:13:25, 29 Mar. PPP LCP Receive Configuration ACK
08:13:25, 29 Mar. PPP LCP Send Configuration ACK
08:13:24, 29 Mar. PPP LCP Send Configuration Request
08:13:24, 29 Mar. PPP LCP Receive Configuration Request
08:13:13, 29 Mar. PPP LCP Receive Configuration ACK
08:13:13, 29 Mar. PPP LCP Send Configuration Request
08:13:10, 29 Mar. PPP LCP Send Configuration Request
08:13:07, 29 Mar. PPP LCP Send Configuration Request
08:13:03, 29 Mar. PPP LCP Send Configuration Request
08:13:00, 29 Mar. PPP LCP Send Configuration Request
08:12:57, 29 Mar. PPP LCP Send Configuration Request
08:12:54, 29 Mar. PPP LCP Send Configuration Request
08:12:51, 29 Mar. PPP LCP Send Configuration ACK
08:12:51, 29 Mar. PPP LCP Receive Configuration Request
08:12:51, 29 Mar. PPP LCP Send Configuration Request
08:12:48, 29 Mar. PPP LCP Send Configuration Request
08:12:14, 29 Mar. PPP LCP Send Configuration Request
08:12:11, 29 Mar. PPP LCP Send Configuration Request
08:12:08, 29 Mar. PPP LCP Send Configuration ACK
08:12:08, 29 Mar. PPP LCP Receive Configuration Request
08:12:08, 29 Mar. PPP LCP Send Configuration Request
08:12:05, 29 Mar. PPP LCP Send Configuration Request
08:12:02, 29 Mar. PPP LCP Send Configuration Request
08:11:59, 29 Mar. PPP LCP Send Configuration Request
08:11:56, 29 Mar. PPP LCP Send Configuration Request
08:11:52, 29 Mar. PPP LCP Send Configuration Request
08:11:49, 29 Mar. PPP LCP Send Configuration Request
08:11:46, 29 Mar. PPP LCP Send Configuration Request
08:11:43, 29 Mar. PPP LCP Receive Configuration ACK
08:11:43, 29 Mar. PPP LCP Send Configuration Request
08:11:40, 29 Mar. PPP LCP Send Configuration Request
08:11:39, 29 Mar. WAN connection ATM disconnected
08:11:33, 29 Mar. PPP LCP Receive Termination ACK
08:11:32, 29 Mar. PPP LCP Send Termination Request (Peer not responding)
06:46:31, 29 Mar. DoS(UDP Loopback): IN=ppp1 OUT= MAC= SRC=184.105.139.105 DST=86.140.164.55 LEN=29 TOS=0x00
Times 18:19:23 WAN to 09:49 is the clue to me. I am not pressing the restart button! Note BT HUB 4B ADSL(0) Max not 2+
Seams a very long time of no PPP session before retrain?
Will try to find better hub 6a example later maybe tomorrow.
Thanks for helping.
I may also still have a line fault or R.E.I.N. I'll explain later.
Ta.
-
Any one know how to edit the title of this thread.
loss sync = BT speak and miss spelt.
without retrain. Correct language and spelling?
-
Forgot pin the tail on the donkey. No pinning it on me unless absolutely necessary.
Humor helps BT woes.
-
This is the QoS I am talking about.
Is my PPP L2TP?
-
Can't see the forest for the trees?
-
Any one know how to edit the title of this thread.
loss sync = BT speak and miss spelt.
without retrain. Correct language and spelling?
Silently, stealthily, just like a ninja, the kuro neko performs the deed. :D
-
Yep you got the plot.
Icdith is balck, welsh and proud of it but he does answer to kuro neko when translated into Welsh and delivered in an appropriate accent.
He is in the words of John Sparkes 'The last thing you want up your street'
PPP tail on donkey?
Spot the black hole?
-
My go tail on donkey.
A= R.E.I.N or copper fault.
B= Openreach 'fault'.
C= ISP 'fault'.
-
Silently, stealthily, just like a ninja, the kuro neko performs the deed. :D
Ta for correcting spieling mistakes no spell check is imune from my typeing.
As for Silently, stealthily, just like a ninja with a club foot. I resemble that comment!
Any how Gwyneth has got rats again and Icdith is parking his 'van-u-like' 'up your street'.
I am Absolutely serious about my 'black hole'. Best Effort(0) Dropped. Should be ?(7) ? tosh/NotTosh?
-
The xDSL link breaking (a retrain) will result in the PPP link breaking.
The PPP link disconnecting would have no impact on the xDSL link.
In respect of the rules I am posting a link to community BT and I am also lazy.
https://community.bt.com/t5/ADSL-Copper-broadband/PPP-Dropouts-during-day-remote-station-is-not-answering-to-LCP/td-p/1940705/page/3
Page 3 is my question. Save you a read.
I'm also lazy.
I haven't read the BT thread but all I can see from the logs is that the DSL link is breaking.
Too much unrelated stuff in the logs which also show in reverse, it's difficult to tell what I'm supposed to be looking for.
-
Thanks for reply.
The PPP is more breaking thus disconnecting.
The loss of ?LCP echo packets is causing my end to bring down PPP session and retry while xDsl is still up.
The symptom is everything grinds to a halt. Ususl at congersted times but should get going again.
Mine will slow down, PPP echo's x 6? not answered, stop PPP session restart PPP with new external IP.
There are two patterns. I've had a serious line fault for 12months masking this symptom.
With fault 90% of time PPP lost then xDSL link will go down 60 to 90 seconds later. 10% PPP reestablished and carry on.
Now fault fixed, line still training, when it does it 2-3 times a week I'm generally when doing something important.
It will now 90% drop PPP reestablish PPP and carry on. 10% a retrain will occur 60-90s later.
I have two theories 1. R.E.I.N 2. 'black holeing' LCP echo requests getting dropped after xDSL link.
1. I have de rein'd my place late 2018. Everything from toaster fridge boiler ...... x rated capacitors, filters mu metal shielding the lot.
before I retired I worked in pro audio. We call it noise no rein. Spent many years finding clics, pops and hums on FST twisted pair.
I am going to dump BT hub soon and start graphing my SNR in real time. Will check for impulse noise then.
2. I personally think this is my problem. Backhaul load balancing packet filtering and Best Effort.
All of my control data and ordinary data are being tagged BE or not, if no tag they get default BE tag.
I expect also BT are intentionally dropping some control traffic, saving bandwidth for them, all the time anyway.
At times of congestion because all my data is BE it will drop enough PPP control packets to make PPP drop and reestablish.
It would appear if this takes more than 60 seconds ish BT firmware will bring down xDSL as a turn it off then turn on style fix.
I suspect my line is misconfigured , or I need a business 'product' for this configuration,or a radius server malfunctioning.
As with everything BT they talk s...e. retrain = loss of sync. training = stabilisation rate cap = we don't do caps(yet they do) etc ...
BT take the p..s most of the time. Use the 'wrong' language and you find another black hole.
Mention PPP to level 1 and they start banging on about interleaving. God forbid you mention the blue light stays on.
Blue light = get the cables out and have another hour of my time wasted. Nothing wrong with my side.
For 12 months my ADSL has had DLM off and SNR target locked to 6dB. Software fudge to 'fix' hardware(line) fault.
After fixing line fault, 40+ engineers have worked on it in 12 months, upgrade to ADSL2+ DLM on SNR floating.
But if BT, Level1 or Openreach 'reset' my line it goes DLM off SNR locked.
BT said it cold not happen but it did. They now 'say' it won't happen in the future.
I suspect 'the it won't happen again' is an assumption based default behavior and not my actual line settings.
So as BT don't care I am left to diagnose the fault my self.
Find the correct BT speak to describe it.
Then give the f...g bunch of c..s the biggest b.....g they have ever had in there lives.
In 1990's I got bt regional manager out of bed at 4am on a Sunday morning.
When he arrived in my office at 5:30am he got a right b......g for cutting off 25+ lines for no reason at all.
But I was a business customer not a retail where all BT customers are called Terry F...wit.
6 months and I'm off. Sorry for the ranting.
-
With fault 90% of time PPP lost then xDSL link will go down 60 to 90 seconds later. 10% PPP reestablished and carry on.
This suggests the fault lies in the copper xDSL link, not anything backhaul related.
As mentioned above
The xDSL link breaking (a retrain) will result in the PPP link breaking.
The PPP link disconnecting would have no impact on the xDSL link.
The fact the logs mention the PPP link is disconnecting 1st is irrelevant.
Sounds like you are over thinking this also.
-
Thank for input. Line fault is now fixed.
Now fault fixed, line still training, when it does it 2-3 times a week I'm generally when doing something important Edit: at peak times.
It will now 90% drop PPP reestablish PPP and carry on. 10% a retrain will occur 60-90s later.
I have two theories 1. R.E.I.N 2. 'black holeing' LCP echo requests getting dropped after xDSL link.
Over Thinking is my middle name!
Ta.
-
I think to answer my question I need one piece of information.
Does any one know how BT(ISP) WBC(Openreach) ADSL1(Max) and ADSL2plus establish a PPP session?
PTA mode or L2TP mode?
Is this arrangement ISP specific? ie Small ISP PTA BIG L2TP
This will hopefully ctrl alt delete my over thinking and stop me waffling.
And stop me getting a full reboot from the wife for not cutting the grass!
Unless the sound of my typing wakes the dragon. Thanks again.
-
Digger, ADSLx has absolutely nothing at all to do with PPP or L2TP. PPP was in use 23 years ago in the dialup days before ADSL existed. Iirc some ISPs do not use PPP with internet access at all, rather using other protocol stacks. See http://wand.cs.waikato.ac.nz/~513/2006/readings/adsl-2.pdf
Kitz has talked about the business of setting up PPP links with internet access. If memory serves, the user initially connects to the BT ‘BRAS’ server - see Kitz’ articles on how internet access works which have a diagram of nodes and links in the access provision network. The BRAS server handles user login with something like bob@my.isp and can (optionally?) give out IP addresses too as instructed by the ISP.
It is a bit strange in protocol terms because first the user’s router is talking to the BRAS, and then the BRAS goes transparent and after that point your are talking through the BRAS to a server at the ISP. During this later phase the user is exchanging data with the ISP using PPP packets. (We are supposed to call these packets ‘frames’. I don’t care.)
L2TP is used for the link between BRAS and the LNS server at the ISP. It carries user data. L2TP can be used between your own router or your own machine and an LNS at your ISP or at your company HQ. It’s a tunnel protocol that is an insecure VPN because as it comes out of the box there’s no encryption included. Aside from the usual role in internet access with wholesale carriers, a very different example: for £10 + VAT per month you can connect your router or other machines of yours to the ISP AA.net.uk and use their services to access the internet even though you are accessing them using some other ISP or service, could be anything, some other DSL, or 4G or a wireless network in a café. L2TP takes PPP packets for example and carries them down a tunnel to l2tp.AA.net.uk. See https://www.aa.net.uk/broadband/l2tp-service
Is L2TP ISP-specific ? - in the usual wholesale L2TP is between wholesale carrier and ISP - kitz or one of our experts could answer this question. My ISP uses L2TP and I would have thought a great many do, but everyone? Some ISPs use their own network to get data from the exchange to their own core kit rather than using a wholesale carrier - LLU operators are often like this, so they could do whatever they like, but that doesn’t tell us much. Over to others who know what’s what.
Sorry I couldn’t be of much help, don’t know enough isps.
‘
-
Weaver, Thanks for reply.
You must be a mind reader I was going ask you about AA. I'm considering Aquiss.
https://www.btplc.com/SINet/SINs/pdf/472v2p9.pdf
This is the current document on wholesale? website WBC 'product'
This is how my current adsl2plus service is curently described as being supplied.
With reference to this 'language' and it's 'proper' name.
Router remains 'synced' for three days.
Day two 10:30am no internet. 10:32am internet back with different external dynamic IP?
What mechanism or concept would you have to 'break' to observe this behavior?
Infrastructure upgrades software etc. is usually done at 4am.
I can then reverse engineer your answer into language BT/Openreach speak.
I suspect in my language that my session control traffic is getting dropped at congested times.
I expect this to happen with my data but not to dump my current session at the same time.
My router makes a 'link' to the exchange, my xDSL.
My router then makes a different link using the xDSL link to my ISP ie the internet.
What else could cause the link to fail apart from the xDSL link failing?
PPP LCP Send Termination Request (Peer not responding)
This appears in router log when this happens.
Sorry to bang on. Any Ideas?
-
Probably not that helpful but I can confirm that I've also been having a fault where the PPP drops while DSL remains in sync, sometimes for hours. PPP only comes back by initiating a DSL retrain. I know DSL is staying in sync because the router shows this, complete with variations in SNR and incrementing counters to show it's not just frozen at the last known set of stats. Also on A&A's portal you can get a sync status report from BT, and that also shows the line in sync. Getting Openreach to believe is a different matter - even after getting all the facts from AA and from me they keep referring to what might be causing it to "lose sync".
-
A matter of correct language and identify the owner of kit responsible.
I suspect an over zealous/worked backhaul router. Where of who impossible to find out.
I am also expecting Openreach again tomorrow. Tea, cake and football chat then. FA will get done.
I'll keep digging.
-
I realise that I forgot to say that the link drops could be due to an echo request-response pair in the d/s-request-then-u/s-response direction which is initiated by the Firebricks at the A&A end which always do such monitoring. So if I were corrupting anything sent upstream, it could be an echo response that is being corrupted. Those remote Firebrick’s LCP link monitoring timers are iirc not user-controllable to such a fine degree; I don’t recall seeing any facility for users to enter values for timeouts. There is however a 1-bit control, "fast" ie. short or normal timeout. The clueless.aa.net.uk help file says
Quote
LCP echoes usually stop responding if the line has gone down. Our LCP monitoring, which produces the graphs, will drop the line if there are no replies after 60 seconds. When bonding or used in a fall-back setup, having a faster timeout is useful in order to fall-back quicker.
Above from. https://forum.kitz.co.uk/index.php/topic,23382.msg396417.html#msg396417
LCP echoes usually stop responding if the line has gone down.
Is not the same as
Our LCP monitoring, which produces the graphs, will drop the line if there are no replies after 60 seconds.
LCP echoes usually stop responding if the line has gone down.
The word 'usually' is strange if the line is down, I presume they mean loss of sync by line down. It is 'normal' no sync nothing gets through. Everything breaks.
Our LCP monitoring, which produces the graphs, will drop the line if there are no replies after 60 seconds.
Ie line in sync but no LCP arriving at ISP. ISP thinks PPP link broken and can only resyncs line to fix lost session.
It appears to work in the opposite direction. Your router does not receive a reply to LCP echos x 6(normally). Bring PPP session down. It will try to reestablish PPP as in sync. If that fails router will resync to solve loss of IP connectivity not because of loss of sync as it is already in sync.
So where is all this dropping happening?
Somewhere inside WBC I am sure?
A LNS to Radius link maybe?
An ISP radius server /The ISP would fix that.
This generally happens at times of congestion in my case.
@aesmith . Have you got any more info on this. Logs etc.?
-
Without any monitoring of when CRC errors are occurring on the DSL link, it's not possible to know when stuff is being lost in transit over the DSL link. It's possible to have enough errors that everything, including what's keeping the PPP connection alive, will be lost, but without the DSL link retraining.
-
10 day training/stabilisation over. 6A to shed out with a Billion. Can report proper data then. Thanks.
It's possible to have enough errors that everything, including what's keeping the PPP connection alive, will be lost, but without the DSL link retraining.
Does this mean as long as SNR stays above 0dB all PPP control data can be lost causing PPP to reconnect when CRC errors reduce?
-
Does this mean as long as SNR stays above 0dB all PPP control data can be lost causing PPP to reconnect when CRC errors reduce?
Yes, it's possible. Sometimes things will even stay connected with a negative SNRM.
-
I have had many occasions with a number of Netgear DG834v3 modems where SNRM can momentarily go negative and they do not drop the dsl link, and PPP is completely unaffected. (The displayed text was hilarious, with integer overflow, until Netgear fixed the software to display something sensible for negative SNRM values.)
-
Yes, it's possible. Sometimes things will even stay connected with a negative SNRM.
I understand the -0dB thing I have observed it many times.
What I don't understand is how noise/interference/line fault can be so selective?
As CRC is ATM error checking and correction ......
I need to think about this one.
-
I have had many occasions with a number of Netgear DG834v3 modems where SNRM can momentarily go negative and they do not drop the dsl link, and PPP is completely unaffected. (The displayed text was hilarious, with integer overflow, until Netgear fixed the software to display something sensible for negative SNRM values.)
Sorry cross posted. Seen it on DG834GT many times.
It is not my question. But thanks.
need to sleep/think