Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[faqinel]

Hoping some of the wise heads on here can shed a little light on my problem with my TT Fibre connection.

A little history

I have been with TT Business for three years now on ADSL via their LLU at the Kirkbymoorside exchange https://www.samknows.com/broadband/exchange/MYKMS on a good line, a short distance from the exchange and have had a faultless service with good speeds.
When a cabinet was eventually installed, to service the exchange only lines, I transferred to Fibre three weeks ago.  The managed installation was by BTOR and I was left with the Talk Talk 635 Super Router.  The line tested well and I was synced at 79/19.

Every day since I have experienced several disconnections per day usually lasting at least half an hour.
At all times the line remains synced but I experience the following:
1. noticeable slow down in resolving websites.
2. after 5 - 10 minutes the authentication drops.
3. 5 - 10 minutes after that the connection is back up.
4. 5 - 10 minutes of very slow broadband before going back to full speed.

I initially removed the HG 635 and installed a Fritzbox 7490.  The Fritzbox would report PPPOE timeout errors.  If left alone it would eventually authenticate but this would take at least 30 minutes and occasionally over 1 hour.  The only way to negate this was to pull the DSL cable and leave it for ten minutes. On reconnection the router would sync and authenticate within a couple of minutes and I would get a full speed connection.
For the last week I have had the HG 635 connected via the VDSL port (to help minimise the excuses from TTB) but still see the same issue.
I also have TT Fibre at home, again on an exchange only line to the same cabinet, and experience the same issue.  I also know of two other customers on the same cabinet (via BT) who have reported frequent disconnections and subsequent slow reconnections.  This may be a red herring but possibly relevant.
I will post some Tracert results taken during the downtime and also the results of Think Broadband's Ping Quality Monitor once I have collated them.

Talk Talk support have been aware of this issue for three weeks now and where possible I raise every outage.  So far they have sent an BTOR engineer out twice to check the line and like the initial installation the line has tested out fine.  The fact that I have never lost sync would also seem to confer that the line is OK.

As well as looking for some insight in to what may be happening I would also appreciate some advice on how best to progress this through technical support.  Despite raising the issue with the CEO and getting bumped up the support tree TT seem reluctant to do anything other than tinker with my router settings and run line checks.

Thanks in advance.

[WWWombat]

Seems indicative of intermittent large-scale packet loss somewhere, but with little clue where. The fact that some of the tracerts show a loss in the second row suggest it is somewhere before that - so could be almost anywhere in TT or Openreach.

I guess you need to do something to distinguish whether the problem lies in your line, or beyond. Ordinarily, graphs from DSLstats or HG612-Modem-Stats would be the prescription, allowing you to track the error events on your line, and correlating the PPPoE event log (and authentication drops) against anything seen on the line. However, I'm not sure what devices you can use with a TT connection.

Your TBB BQM's will add something to the mix, as they show packets coming from the other side. However, while I suspect they will also show lots of packet loss, they probably don't help us identify *where*.

[AArdvark]

However, I'm not sure what devices you can use with a TT connection.

FYI:
DSLStats supports the HG635. (It is in the dropdown menu to select modem).

[burakkucat]

Just a quick suggestion . . . but first a question. Does the TT "SuperRouter" have a WAN socket? 

If yes, then perhaps you could obtain a Huawei HG612, unlock it (by flashing it with Wolfy's most recent firmware image) and then insert it between the incoming line and the "SuperRouter". You would then be all set up to use one or the other of the well known statistics gathering utilities to see what is happening on your circuit at the most fundamental level.

The fact that your circuit is one that has been part of a network rearrangement, the original installing and two subsequent Openreach technicians have pronounced that the metallic pathway is without fault (synchronisation obtained at the maximum 79/19 Mbps) makes me wonder if the problem is with TT's software at the PPPoE authentication layer and/or beyond.

(b*cat wonders if a friendly W³ombat would go along with that idea?    )

[Edit -- I see that AArdvark has posted before me with an even simpler suggestion.]

[jid]

However, I'm not sure what devices you can use with a TT connection.

FYI:
DSLStats supports the HG635. (It is in the dropdown menu to select modem).

I did this and using the custom configuration file caused issues with ports not closing on the wan 

However you're free to use whatever device you want, b*cats suggestion is a good one, the Super Router does support the Openreach modem on the Wan, I was myself doing this for a while before buying a new router.

[WWWombat]

The fact that your circuit is one that has been part of a network rearrangement, the original installing and two subsequent Openreach technicians have pronounced that the metallic pathway is without fault (synchronisation obtained at the maximum 79/19 Mbps) makes me wonder if the problem is with TT's software at the PPPoE authentication layer.

(b*cat wonders if a friendly W³ombat would go along with that idea?    )

I'd agree that it doesn't, on the face of it, appear to be a problem with the VDSL2 connection.

But whether the issue can be pegged to PPPoE authentication, I'm not sure. For any IP packets to get through from the OP to the internet, PPPoE must have authenticated once, and be considered (at the BRAS) to be authenticated. When the OP gets the failure, he seems to see PPPoE authentication failures in the router log (so the router thinks there are issues, even if the BRAS doesn't yet), but he also sees a mixture of both failure and success at IP level in the tracert results.

I suspect that the underlying problem is plain packet loss - and that some of them are PPPoE packets, while some are IP packets. Yet some packets get through fine - certainly some IP packets, and probably some PPPoE packets too. When PPPoE maintenance packets start to go astray, you get timeout issues in the router - and probably get the router trying to confirm that it is still authenticated, along with log messages. Meanwhile, the BRAS may not timeout so quickly ... so some IP packets (those that get as far as the BRAS) get through to the internet, and get a response.

Eventually, of course, the BRAS probably times out too, and will refuse to consider the user as authenticated - so IP packets will fail completely.

Or, alternatively, enough PPPoE packets get from router to BRAS, and the problem is that the responses fail to get back. The BRAS would probably stay connected for longer that way, depending on the exact sequence of confirmation packets needed.

All the OP can do, at first, is to rule out his equipment, and rule out his line performance.

[boost]

Your 79 is already down to 66 so I would be looking to blame the copper or some local~ interference before anything TT side.

Commence with the HLOGs and QLNs!

[faqinel]

Thanks for the quick replies.

However, I'm not sure what devices you can use with a TT connection.

FYI:
DSLStats supports the HG635. (It is in the dropdown menu to select modem).

I don't, at this stage, want to hack the Talk Talk router.  I have an ECI Openreach modem but will order an HG612 tomorrow.

All the OP can do, at first, is to rule out his equipment, and rule out his line performance.

So far I have tried the following combinations:

Openreach ECI modem with HG635 via WAN
ECI modem with Fritzbox
HG635 as VDSL
Fritzbox as VDSL

The line was a managed install with DSL filtered at faceplate.  There are no extensions and only a single DECT base station (Fritzbox) connected.  Is there anything else you would recommend trying?

Your 79 is already down to 66 so I would be looking to blame the copper or some local~ interference before anything TT side.

Commence with the HLOGs and QLNs!

The drop in speed from the initial 79 came after the first OR engineer visit.  Although he could find no issue with the line he swapped to another pair 'just in case'. This seemed reasonable at the time but did leave me 10 meg down.  I also lost 2 meg upload sync.  The symptoms were neither alleviated nor made worse.  I will post some stats once I get the HG612 installed.  Is there a preference to use DSLStats or HG612 Stats?

As stated I find that if I pull the dsl cable for ten minutes when I realise I have a connection issue then I sync up and authenticate almost immediately and at full speed, with no dropped packets.  Is this triggering a reset at the exchange?  If the issue is packet loss due to line quality then would I not still see issues when I pull the DSL cable?

I should have the HG612 by Tuesday and also some results from TBB Quality Monitor.  The Tracert results I grabbed today are indicative and I managed to cover the full sequence from the initial slow response through disconnect and reconnect.

Thanks again for your input

[boost]

Ah, my bad!

Did you also say there are other (FTTC) customers off that cab with identical issues and presumably flawless lines? I wonder if this is a mouldy cabinet problem?

[faqinel]

I signed up to Thinkbroadband yesterday and managed to capture the outage at 3:00

Snapshot covering Sunday afternoon outage.  The Tracert results cover this snapshot.


Live Stream


Will hopefully get the HG612 tomorrow and be able to post some stats from that.

[guest]

The fact a different router will take 30-60 minutes to auth suggests a DHCP lease hasn't expired.

Pulling the cable for 10 minutes+ is an old trick which worked on BT-provided ADSL (reset the port on the DSLAM/MSAN or similar) but never did on Sky, haven't tried it on VDSL2.

[faqinel]

The fact a different router will take 30-60 minutes to auth suggests a DHCP lease hasn't expired.

Pulling the cable for 10 minutes+ is an old trick which worked on BT-provided ADSL (reset the port on the DSLAM/MSAN or similar) but never did on Sky, haven't tried it on VDSL2.

I have a block of four static IP's

OR engineer arrived again today. Line tested OK.  Pulled the dsl and reconnected - DSL up straight away, 20 minutes to authenticate.  He spoke to TT who requested a lift and shift but this was declined by BTW.  TT then rang back later and said that they now have agreement with BTW to do the lift and shift.

Can anyone advise whether this is a physical operation carried out at the cabinet or something done remotely because TT said it would happen over night.

Thanks.

[Black Sheep]

The correct terminology is everything. This isn't having a dig at you mate, I'm just pointing out that one mans 'Lift & Shift' is another mans 'E-side change'.

The engineer can try and request a 'L&S' until he's blue in the face with the ISP, they have no say in it. One can only be given by liaising with our 'Diagnostic Centre of Excellence' <giggles to himself at the jumped up title icon>, and going through various procedures with them whilst at the actual Cab itself. I've never heard of the scenario you mention taking place before ?? Still, stranger things have happened at sea.

To answer your question though, the 'L&S' is a 5 minute physical operation. Basically connecting your landline dial-tone through to the new VDSL port, and then back out to your ongoing wires to your house. 

[faqinel]

The correct terminology is everything. This isn't having a dig at you mate, I'm just pointing out that one mans 'Lift & Shift' is another mans 'E-side change'.

The engineer can try and request a 'L&S' until he's blue in the face with the ISP, they have no say in it. One can only be given by liaising with our 'Diagnostic Centre of Excellence' <giggles to himself at the jumped up title icon>, and going through various procedures with them whilst at the actual Cab itself. I've never heard of the scenario you mention taking place before ?? Still, stranger things have happened at sea.

To answer your question though, the 'L&S' is a 5 minute physical operation. Basically connecting your landline dial-tone through to the new VDSL port, and then back out to your ongoing wires to your house. 

It was TT who requested the lift & shift.  When the engineer relayed this to BT it was declined. His words 'they could not justify the cost of flagging the port as faulty'.  TT now say they have got authorisation from BTW and it will happen.  I was just puzzled as to when.  It seemed unlikely that this would happen late evening or in the early hours, as my limited knowledge envisioned my copper pairs being physically 'patched' in to another port, which you seem to confirm.  I am also expecting some down time which as yet has not happened.