PPP LCP Send Termination Request [User request]

[Stuey3d]

From my understanding DLM lives in the equipment in the green street cabinets and is designed to detect instability between your equipment and the cabinet equipment, so just the last couple of meters - few hundred meters of line depending on how close you are to the cab.

These "PPP LCP Send Termination Request [User request]" disconnects are not causing your equipment to loose sync with the street cabinet equipment as the stats are remaining identical rather than re-syncing and the disconnects are extrememly quick as opposed to taking the full few minutes a normal disconnect does, therefore it appears that DLM is not getting the chance to detect any instability between your equipment and the street cabinet and therefore theoretically it will not act to stabilize the line as that part is already stable.

These disconnections are different to the OpenRG disconnections others are also experiencing as they are causing the hub to fully restart and completely drop and reconnect the connection and they take a good few minutes to complete and will cause DLM to kick in.

I honestly believe BT are doing something further down the network, perhaps in a data centre somewhere which assigns the IP addresses or something as it appears that the Hub recieves some remote admin and value changes and then a while after you get a split second disconnection so fast that the hub status light doesnt even turn orange and normal browsing isnt effected, streaming/online gaming/voip calls will be the main things effected by these disconnections which then becomes very frustrating indeed.

[UmbertyUmberty]

Getting the OpenRG events as well as the PPP LCP Send Termination Request [User request] events.

Only show up when I filter for 'System' instead 'All' for some reason.

14:15:21, 05 Feb.	( 29.810000) The system is UP!
14:14:24, 05 Feb.	(11483.720000) The system is going DOWN for reboot.
14:14:24, 05 Feb.	(11483.720000) OpenRG is going for reboot by IPC command
14:14:19, 05 Feb.	(11478.720000) OpenRG will go down for reboot in 5 seconds
11:03:31, 05 Feb.	( 29.310000) The system is UP!
11:02:34, 05 Feb.	( 5967.750000) The system is going DOWN for reboot.
11:02:34, 05 Feb.	( 5967.750000) OpenRG is going for reboot by IPC command
11:02:29, 05 Feb.	( 5962.750000) OpenRG will go down for reboot in 5 seconds

[Stuey3d]

---

@UmbertyUmberty wrote:

Getting the OpenRG events as well as the PPP LCP Send Termination Request [User request] events.

Only show up when I filter for 'System' instead 'All' for some reason.

14:15:21, 05 Feb.	( 29.810000) The system is UP!
14:14:24, 05 Feb.	(11483.720000) The system is going DOWN for reboot.
14:14:24, 05 Feb.	(11483.720000) OpenRG is going for reboot by IPC command
14:14:19, 05 Feb.	(11478.720000) OpenRG will go down for reboot in 5 seconds
11:03:31, 05 Feb.	( 29.310000) The system is UP!
11:02:34, 05 Feb.	( 5967.750000) The system is going DOWN for reboot.
11:02:34, 05 Feb.	( 5967.750000) OpenRG is going for reboot by IPC command
11:02:29, 05 Feb.	( 5962.750000) OpenRG will go down for reboot in 5 seconds

---

Do a factory reset that will get rid of the OpenRG reboots but the "PPP LCP Send Termination Request [User request]" will come back, I had exactly the same.

Its the OpenRG reboots which will cost you speed as its these which DLM will kick in for.

[Storm]

Well that didn't last lomng, I've just had this again less than an hour ago:-

14:39:28, 06 Feb.	(172550.870000) CWMP: session completed successfully
14:39:27, 06 Feb.	(172550.380000) CWMP: HTTP authentication success from https://pbthdm.bt.mo
14:39:22, 06 Feb.	(172545.420000) CWMP: Server URL: https://pbthdm.bt.mo; Connecting as user: ACS username
14:39:22, 06 Feb.	(172545.410000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
14:39:19, 06 Feb.	(172542.390000) WAN operating mode is VDSL
14:39:19, 06 Feb.	(172542.390000) Last WAN operating mode was VDSL
14:39:18, 06 Feb.	(172541.500000) PPP IPCP Receive Configuration ACK
14:39:18, 06 Feb.	(172541.490000) PPP IPCP Send Configuration Request
14:39:18, 06 Feb.	(172541.490000) PPP IPCP Receive Configuration NAK
14:39:18, 06 Feb.	(172541.480000) PPP IPCP Send Configuration ACK
14:39:18, 06 Feb.	(172541.480000) PPP IPCP Receive Configuration Request
14:39:18, 06 Feb.	(172541.480000) PPP IPCP Send Configuration Request
14:39:18, 06 Feb.	(172541.480000) CHAP authentication successful
14:39:18, 06 Feb.	(172541.380000) CHAP Receive Challenge
14:39:18, 06 Feb.	(172541.380000) Starting CHAP authentication with peer
14:39:18, 06 Feb.	(172541.380000) PPP LCP Receive Configuration ACK
14:39:18, 06 Feb.	(172541.370000) PPP LCP Send Configuration Request
14:39:18, 06 Feb.	(172541.370000) PPP LCP Receive Configuration Reject
14:39:18, 06 Feb.	(172541.370000) PPP LCP Send Configuration ACK
14:39:18, 06 Feb.	(172541.370000) PPP LCP Receive Configuration Request
14:39:18, 06 Feb.	(172541.370000) PPP LCP Send Configuration Request
14:39:16, 06 Feb.	(172539.440000) CWMP: session closed due to error: Could not resolve host
14:39:16, 06 Feb.	(172539.360000) CWMP: Server URL: https://pbthdm.bt.mo; Connecting as user: ACS username
14:39:16, 06 Feb.	(172539.360000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
14:39:16, 06 Feb.	(172539.150000) CWMP: Initializing transaction for event code 4 VALUE CHANGE

The sync speed and connection speed are the same however my ip address has changed again. Whilst I appreiociate this is a dynamic service I need to remote into my pc at times when I'm workign away. I used to get connections that gave me the same ip for 2 or 3 months now I'm lucky if it's hours!

Come on BT what the hell is going on here and if you can't fix this give me a free static ip!!!!

[Storm]

Just done it again 20 mins ago.

Still same speed and connection but ip has changed yet again and connection time has reset again.

[Stuey3d]

Yeah it looks like its as i suspect they are having problems further down the network which is causing this problem for us.

[infinidim]

---

@Stuey3d wrote:

As I keep pointing out check your stats sync/max attainable/snr and then check them after a disconnect and they will be identical which should mean DLM wont kick in as you are not actually disconnecting from the street equipment but further down the network and DLM lives in the street equipment, it hasnt for me yet *touch wood* and this has been going on a while.

Max attainable/snr are constantly changing due to local conditions but the Sync rate will be exactly the same and the max attainable and snr will be around the same as it was before the "PPP LCP Send Termination Request [User request]" disconnect.

---

Not quite true about where the DLM sits in the network. The monitoring is carried out in the VDSL DSLAM in  FTTC cabinets and at the DSLAM's in the exchanges. The actual systems sites that look at the information that has been polled from the various devices sit in BT's datacenters. Basically all DLM is is an algorithmic system that "if it sees this is does that, or if there are frequent changes it does something else etc."

[infinidim]

---

@Stuey3d wrote:

Yeah it looks like its as i suspect they are having problems further down the network which is causing this problem for us.

---

This is almost certainly further into the network. Looking at what I have seen so far, it's not in the copper section between the property and the PCP or the connection between the PCP and the FTTC cabinet. It's not in the cabinet  - I don't think currently. It's not in the local exchange either I don't think. It could be in the BRAS (Broadband Remote Access Server) or it could be at the MSIL ( Multi Service Interconnect Link ),. From what I have seen so far I think it could be an issue between the Home Hub 5 firmware / software and the BRAS. It can only be this because the Home Hub 4 seems to work well on Infinity 1 and 2 with no similair issues.

Gut says that it's a timing parameter in the Home Hub 5 that BT should be able to find quite quickly.

[Stuey3d]

Lets hope they fix this and the firewall/wifi freezing issue all in the next firmware and lets hope its quick.

[infinidim]

---

@infinidim wrote:

---

@Stuey3d wrote:

Yeah it looks like its as i suspect they are having problems further down the network which is causing this problem for us.

---

This is almost certainly further into the network. Looking at what I have seen so far, it's not in the copper section between the property and the PCP or the connection between the PCP and the FTTC cabinet. It's not in the cabinet  - I don't think currently. It's not in the local exchange either I don't think. It could be in the BRAS (Broadband Remote Access Server) or it could be at the MSIL ( Multi Service Interconnect Link ),. From what I have seen so far I think it could be an issue between the Home Hub 5 firmware / software and the BRAS. It can only be this because the Home Hub 4 seems to work well on Infinity 1 and 2 with no similar issues.

Gut says that it's a timing parameter in the Home Hub 5 that BT should be able to find quite quickly.

---

I have been thinking a bit more about this issue. Given that not all Home Hub 5 users seem to be having this issue as far as I am aware then this issue could very well be at the BRAS. The reason why I say this is because I believe that BT use two different manufacturers of BRAS - Cisco and Juniper. Maybe one of these is set-up differently so causes the issue that we are seeing.

I will think more about this one and post my thoughts here.