Disconnects

[SpencerUk]

It's far from ideal to have to put up with disconnects, however it needs to be noted, no ISP can really guarantee a fault free long ongoing session either.

@TTM13 Take it the Cellpipe is in the test socket and you have tried alternate filters already?

[TTM13]

Hi all, loads of replies since the last time I checked, hopefully I've spotted them all!

@mirdragon
I've tried 3 cables that link Cellpipe to master socket in total:
Two normal RJ11 ended cables that you normally get and...
One cat5e cable with a RJ45 connector one end and punched into my ADSLnation faceplate/filter the other. I've tried the normal rj11 cables with both my ADSLnation faceplate and the cheapo supplied filters too.

I've only ever heard from Origin which is usually a line test for a day or two, them changing something (INP I think) and then them asking if it's any better. Never heard anything from Thales, nor have I had any additional equipment sent to me.

@alexatkin
Yes I was with Origin before PPPoE and it was exactly the same - I was hoping the switch to PPPoE would fix the issue

@SpencerUk
The Cellpipe is currently in the test socket - it's been in there since November/December when I first logged this issue (I went through stages of putting up with the disconnects previously). It's currently plugged it with a double ended RJ11 cable into one of the cheapo filters that goes straight into the test socket. Router & Cellpipe sit right next to the master socket so no extensions.

I think that answers everything, thanks for the suggestions everyone

This is todays ping graph, the big red lines are the disconnects:

[TTM13]

It's disconnected just now - the lights on the Cellpipe and router are the same as when it's connected: Cellpipe has DSL light on and no internet light, router has internet light on.

Also, this is from the router log:
Mar 5 19:57:29 tomato daemon.warn pppoe[23612]: LCP appears to be disconnected (pending: 5).
Mar 5 19:57:29 tomato daemon.info pppoe[23612]: Sending LCP Termination-Request
Mar 5 19:57:32 tomato daemon.info pppoe[23612]: Sending LCP Termination-Request
Mar 5 19:57:35 tomato daemon.info pppoe[23612]: Connection terminated.
Mar 5 19:57:35 tomato daemon.notice pppoe[23612]: Disconnected.
Mar 5 19:57:35 tomato daemon.notice pppoe[23612]: Connect time 776.0 minutes.
Mar 5 19:57:35 tomato daemon.notice pppoe[23612]: Sent 58582581 bytes, received 1025003846 bytes.
Mar 5 19:57:35 tomato daemon.info pppoe[23612]: Sending PADT.
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Sending PADI.
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Received PADO.
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Sending PADR.
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Received PADS. SID: 0xC432
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Sending LCP Configuration-Request
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Received LCP Configuration-Request
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Sending LCP Configuration-Ack
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Received LCP Configuration-Ack
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: CHAP authentication succeeded.
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Sending IPCP Configuration-Request
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Received IPCP Configuration-Request
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Sending IPCP Configuration-Ack
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Sending LCP Protocol-Reject
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Received IPCP Configuration-Reject
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Sending IPCP Configuration-Request
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Received IPCP Configuration-Nak
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Sending IPCP Configuration-Request
Mar 5 19:57:45 tomato daemon.info pppoe[23612]: Received IPCP Configuration-Ack
Mar 5 19:57:45 tomato daemon.notice pppoe[23612]: Connected.

Doesn't seem to give a reason why it dies

[mirdragon]

The first line would suggest that origin have not responded to the echo requests which in turn makes your router think the connection has dropped

[alexatkin]

Which sounds identical to your old issue, right?

As for me, I never noticed any problems before the switch to PPPoE but then that is the point isn't it - without PPPoE it would be almost impossible to tell if the connection stalled for a few seconds.

[mirdragon]

(07-03-2013 06:47 PM)alexatkin Wrote:  Which sounds identical to your old issue, right?

As for me, I never noticed any problems before the switch to PPPoE but then that is the point isn't it - without PPPoE it would be almost impossible to tell if the connection stalled for a few seconds.

Yes it does - what happens is a number of requests are sent to your ISP every number of seconds - this is to ensure that the connection is kept alive - if your router does not receive the response then it thinks the connection has dropped, which in turn forces it to fully terminate the connection and start it up again.

So your router may send 3 echo requests every 30 seconds, which is defined by lcp-echo-failure and lcp-echo-intervals. Some may send 4 or 5 every 20 seconds, each router is different and if it don't get a response back then it thinks the connection dropped.

Now if your not using PPPoE as you say it does become almost impossible to tell if the connection has stalled, but you can do it using smoothwall, as it allows you to constantly ping an address to see if it responds and then logs the information into a file.

I had the problem originally before moving to PPPoE and only noticed it as was being disconnected from online games, while everyone else wasn't. And at the same time the wife was having problems with streaming content, where it would just suddenly stop and you got the buffering symbol.

I did ask if it was a fault of the cellpipe early in the diagnostics and it was only when I finally told them I was leaving in December 2011 that they said they were going to send out a new cellpipe. I also have an email from Ripwire stating that they were informed there could be a possible issue with some cellpipes resetting themselves, but if this was the case then you would expect the vdsl to resync.

[alexatkin]

Yeah its not the Cellpipe as I am using the HG612. Its not the router as I swapped over to an Atom.

Like I said its not a huge problem on my connection like the op, but its definitely happening.

Bottom line, it shouldn't be happening. I never had anything like this on Be despite a 3dB profile on a long ADSL2+ with aluminium between the cabinet and the exchange.

The fact is that most people wouldn't notice these problems happening, especially if they are coming from flaky ADSL connections. I wasn't certain until Origin switched to PPPoE and it became obvious from the disconnections.

[mirdragon]

Correct it shouldn't be happening

Yet Thales will say it's nothing on their network, which leaves the issue to be with the ISP

But as I was getting similar issues with Ripwire and OP getting similar on Origin this would suggest it is a network issue which Thales should be looking at resolving

[alexatkin]

We have to hope the new operator comes in soon and goes "holy shit, wtf did they have THIS option enabled for?", click, all fixed.

[jody-ASK4]

It's not only those guys, we (ASK4) have seen these issues since day one. PPPoE just makes it more obvious to the end user as the event is logged, our PPPoE disconnect graphs always make for interesting viewing.....