Threaded Mode | Linear Mode

jody-ASK4 · 05-06-2013, 11:24 AM

(04-06-2013 01:41 PM)alexatkin Wrote: You see that's the interesting thing.

If I switch off my router then when it fires back up it will establish a new session. Now with the new echo timeouts I have set if it stops responding due to Digital Region issues it keeps the current session active. It seems Origin do not tear down the session due to it only being unavailable for 15 seconds or so. At least that is how it seems to work on my connection.

So the question would be if Origin can tell there was packet loss even though it wasn't severe enough to bring the PPP session down?

Unlikely, they'll be logging PPP state changes but not individual echo request/responses as debug info generates shed loads of traffic and increases CPU usage on the AC.

**mirdragon** · (This post was last modified: 05-06-2013 12:09 PM by mirdragon.)

(05-06-2013 11:24 AM)jody-ASK4 Wrote: Unlikely, they'll be logging PPP state changes but not individual echo request/responses as debug info generates shed loads of traffic and increases CPU usage on the AC.

Similar to what I was saying - they would have to be fully monitoring the connection for everything otherwise just PPP drop which I'm sure Ripwire told me even DR would see this on their network, but they only keep logs for short period of time

jody-ASK4 · 08-06-2013, 09:19 AM

RiPWiRE told you DR would see the PPP drops?

**mirdragon** · (This post was last modified: 08-06-2013 12:26 PM by mirdragon.)

(08-06-2013 09:19 AM)jody-ASK4 Wrote: RiPWiRE told you DR would see the PPP drops?

When they got DR made some changes on the line during the time Ripwire asked them to monitor it, I got this feedback.

Quote:DRL have changed the impulse noise protection on your circuit. Since doing this they have not logged any drops

So I think you would have to get DR to monitor a connection and provide logs, etc and then cross-reference to see if can determine issues.

Luckily I have copies of every log and email (including their replies) I raised with Ripwire, which show that even they believed on more than one occasion it had to be an issue with DR. They told me there were x number of customers on my dslam (but as other ISP's involved not the exact amount) which included x (gave me exact amount) of Ripwire customers. They also advised there was a heavy user on my dslam (which I later found out that DR had tried saying it was me, but Ripwire proved it wasn't). Overall I got numerous different reasons for the disconnections with them saying it was all my routers (including the one they recommended)/my line all because I think they had exhausted every avenue with DR/NOC who kept saying there was nothing wrong with the network.

If you remember back when Ripwire ceased trading they also blamed the network

Quote:"We have experienced a host of commercial and technical issues which led to halted roll-outs from major NHS organisations and general network instability for our residential users which grew more and more difficult for us to support on an ongoing basis."

I know I'm no longer a customer on the network, but for the current users on it, I think the current ISP's need to get DR to sort something out - I know it's hard to determine who has a fault or not, but if people are constantly dropping PPPoE this could suggest a network issue especially if the connection is being resumed within less than 30 seconds (as it takes longer to resync the DSL and then re-authenicate if the DSL link dropped)

alexatkin · (This post was last modified: 09-06-2013 02:06 AM by alexatkin.)

But its never going to happen because who is going to risk messing up an otherwise near-perfect connection (ie mine) by moaning to the NOC?

I just know if I said anything they would start cranking up interleaving, INP, reducing my profile, and its CLEARLY none of those things as it wouldn't have been happening when I was on 40/10 if that was the case.

Oh and, 65 days 9 hours 36 minutes 8 seconds in sync and counting....

jody-ASK4 · 10-06-2013, 08:58 AM

(08-06-2013 12:16 PM)mirdragon Wrote:
(08-06-2013 09:19 AM)jody-ASK4 Wrote: RiPWiRE told you DR would see the PPP drops?

When they got DR made some changes on the line during the time Ripwire asked them to monitor it, I got this feedback.

Quote:DRL have changed the impulse noise protection on your circuit. Since doing this they have not logged any drops

So I think you would have to get DR to monitor a connection and provide logs, etc and then cross-reference to see if can determine issues.

Luckily I have copies of every log and email (including their replies) I raised with Ripwire, which show that even they believed on more than one occasion it had to be an issue with DR. They told me there were x number of customers on my dslam (but as other ISP's involved not the exact amount) which included x (gave me exact amount) of Ripwire customers. They also advised there was a heavy user on my dslam (which I later found out that DR had tried saying it was me, but Ripwire proved it wasn't). Overall I got numerous different reasons for the disconnections with them saying it was all my routers (including the one they recommended)/my line all because I think they had exhausted every avenue with DR/NOC who kept saying there was nothing wrong with the network.

If you remember back when Ripwire ceased trading they also blamed the network

Quote:"We have experienced a host of commercial and technical issues which led to halted roll-outs from major NHS organisations and general network instability for our residential users which grew more and more difficult for us to support on an ongoing basis."

I know I'm no longer a customer on the network, but for the current users on it, I think the current ISP's need to get DR to sort something out - I know it's hard to determine who has a fault or not, but if people are constantly dropping PPPoE this could suggest a network issue especially if the connection is being resumed within less than 30 seconds (as it takes longer to resync the DSL and then re-authenicate if the DSL link dropped)

I don't think they're referring to PPP drops there, more like DSL sync and/or Ethernet pseudo-wire drops. DR don't know/care about what is running on a circuit above the Ethernet layer.

**mirdragon** · 10-06-2013, 06:13 PM

The only time DSL dropped was when DR were messing with connection, all other times it was only down while we switched equipment or fully disconnected everything.

Also @alexatkin is further messing with the lcp echo options, which only mask the issue and if went back to standard router would not be able to change these settings and will thus result in being back at stage 1

alexatkin · 10-06-2013, 10:17 PM

67 days 5 hours 47 minutes 24 seconds....

Not sure about PPP as I have been messing with the router which caused several power cycles.

**mirdragon** · 10-06-2013, 11:34 PM

I thought that was your PPP session? Or are you saying you were dropping VDSL if so that different to problem i was having and changing the lcp settings on your router would not affect it.

The hg612 only shows power on and not connection time for vdsl unless there is another setting. I've also not found setting to change lcp settings on it either.

Most routers will reset the connection for pppoe when changing certain settings including WiFi changes

alexatkin · 11-06-2013, 01:30 AM

No, I was pointing out that my VDSL sync is rock-solid stable and only ever drops if I actually tell it to.

For your information, the HG612 shows VDSL connection time in several places. It can be obtained via telnet "xdslcmd info --show", the line AS is how many seconds the line has been in sync. The identical information is also shown on the web interface WAN page under the xDSL tab, labelled as "DSL up time".

I have a custom web page on my router with the JavaScript from the HG612 GUI customised to present the same information while also converting the uptime into mins, hours, days. This is easy as the HG612 does not require you to login to access the JavaScript that contains the DSL information so I directly call http://vdsl.lan/html/status/xdslStatus.asp from my router page, where vdsl.lan is assigned to the HG612 IP on the routers DNS.

PPP of course is monitored directly from my router itself.