Print

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

[Captain Jack]

Hello all,

Since this weekend's storms, I have been having major issues with my FTTC connection. My normal stable sync is around 53-54 Mbit but after a power cut on Saturday, the router (Billion) does sync at the original speed but then comes crashing down within a few minutes, losing sync and resyncing again and again, until it settles on 38Mbit (where it is stable).

This is highly annoying and Zen are reluctant to get the BT engineer out until the line has "settled" after 2-3 weeks and the line is showing no faults.

These are the stats when syncing at a normal speed (but losing it after a few minutes):

Code: [Select]

> adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    1
Last initialization procedure status:   0
Max:    Upstream rate = 9971 Kbps, Downstream rate = 42387 Kbps
Bearer: 0, Upstream rate = 9971 Kbps, Downstream rate = 53847 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State:       L0
Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17a
TPS-TC:                 PTM Mode(0x0)
Trellis:                U:ON /D:ON
Line Status:            Loss Of Margin 
Training Status:        Showtime
                Down            Up
SNR (dB):       -0.2             6.2
Attn(dB):        22.2            0.0
Pwr(dBm):        11.9            5.1
And these are the stats after many, many resyncs at 38Mbit.

Code: [Select]

> adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    1
Last initialization procedure status:   0
Max:    Upstream rate = 9964 Kbps, Downstream rate = 51949 Kbps
Bearer: 0, Upstream rate = 9964 Kbps, Downstream rate = 38269 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State:       L0
Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17a
TPS-TC:                 PTM Mode(0x0)
Trellis:                U:ON /D:ON
Line Status:            No Defect
Training Status:        Showtime
                Down            Up
SNR (dB):        12.6            6.3
Attn(dB):        22.1            0.0
Pwr(dBm):        11.9            5.1
Anyone have any ideas on what can be done to either a) get Zen to report a fault to BTO or b) ...anything else I can do/check?

I've attached my SNRm stats on DSL stats - this looks like a total mess.

Thanks
CJ

[PhilipD]

Hi

Is there any noise on the line if you listen via a telephone?  If yes then report it to your voice provider to get fixed which should then resolve your issues, however upstream seems completely unaffected which sort of rules out a line issue.

It could be a disturber/crosstalker who has a damaged modem/line following the power outage and bad weather and their modem is constantly dropping and sync'ing which is affecting your modems ability to sync nicely, eventually it sync's low enough to ride out the problems and becomes stable.  Waiting a couple of weeks may see the issue resolve when the problematic line/modem is fixed.

Hopefully someone else will have some other suggestions.

Regards

Phil

[Captain Jack]

Nope - no noise on the audible line itself (that issue has been fixed last week!). I tried a different router and a different filter to rule that out but no difference.

It does seem weird that the upstream isn't affected.. hmm. But this surely can't be normal, can it?

[Captain Jack]

I had Zen run the line test again and they are now getting "impairment in copper joint" fault back.

[burakkucat]

I had Zen run the line test again and they are now getting "impairment in copper joint" fault back.

The problem that you are observing could definitely be caused by a faulty joint.

[Captain Jack]

Hi all,

So the original problem with copper joints has been fixed. However, following this, I have two more issues.

The first one is that because of this issue originally and many, many resyncs, I am now stuck on DLM band and cannot sync at more than 48998kbps (and it always syncs at that) despite attainable speed being close to 60Mbit.

The second one is that my connection still gets dropped occasionally, BUT... there's no resync. The sync never drops, just the PPP connection itself and I have to reauthenticate. Here's a typical log from my Billion router:

Code: [Select]

Dec 13 10:38:33 daemon notice syslog: pppd:No response to 2 echo-requests
Dec 13 10:38:33 daemon notice syslog: pppd:Serial link appears to be disconnected.
Dec 13 10:38:33 daemon crit syslog: Clear IP addresses.  PPP connection DOWN.
Dec 13 10:38:33 daemon crit syslog: Clear IP addresses.  Connection DOWN.
Dec 13 10:38:33 daemon notice syslog: pppd:Couldn't increase MTU to 1500.
Dec 13 10:38:33 daemon err syslog: pppd:Couldn't increase MRU to 1500
Dec 13 10:38:39 daemon notice syslog: pppd:Connection terminated.
Dec 13 10:38:39 daemon notice syslog: pppd:Connect time 77.4 minutes.
Dec 13 10:38:39 daemon notice syslog: pppd:Sent 27700040 bytes, received 143064778 bytes.
Dec 13 10:38:39 daemon notice syslog: pppd:Doing disconnect
Dec 13 10:38:42 daemon notice syslog: PPP: Start to connect ...
Dec 13 10:38:46 daemon crit syslog: PPP server detected.
Dec 13 10:38:46 daemon crit syslog: PPP session established.
Dec 13 10:38:46 daemon warn kernel: netdev path : ppp1.1 -> ptm0.1 -> ptm0
Dec 13 10:38:46 daemon notice syslog: pppd:Using interface ppp1.1
Dec 13 10:38:46 daemon notice syslog: pppd:Connect: ppp1.1 <--> ptm0.1
Dec 13 10:38:46 daemon notice syslog: pppd:Couldn't increase MTU to 1500.
Dec 13 10:38:46 daemon err syslog: pppd:Couldn't increase MRU to 1500
Dec 13 10:38:46 daemon err syslog: pppd:Couldn't increase MRU to 1500
Dec 13 10:38:46 daemon crit syslog: PPP LCP UP.
Dec 13 10:38:50 daemon notice syslog: pppd:Couldn't increase MTU to 1500.
Dec 13 10:38:50 daemon err syslog: pppd:Couldn't increase MRU to 1500
Dec 13 10:38:50 daemon err syslog: pppd:Couldn't increase MRU to 1500
Dec 13 10:38:50 daemon crit syslog: PPP LCP UP.
Dec 13 10:38:50 daemon notice syslog: pppd:Remote message: CHAP authentication success, unit 29300
Dec 13 10:38:50 daemon notice syslog: pppd:local  IP address x.x.x.x
Dec 13 10:38:50 daemon notice syslog: pppd:remote IP address 62.3.80.17
Dec 13 10:38:50 daemon notice syslog: pppd:primary   DNS address 212.23.6.100
Dec 13 10:38:50 daemon notice syslog: pppd:secondary DNS address 212.23.3.100
Dec 13 10:38:50 daemon crit syslog: Received valid IP address from server.  Connection UP.
Dec 13 10:38:54 daemon warn kernel: ^[[0;36;44mBroadcom Packet Flow Cache flushing the flows^[[0m
It normally happens in clusters over a few hours but can then be fine for days.

For both issues, Zen isn't interested in helping. I understand that they have no control over DLM and cannot reset it without sending an engineer to the exchange/cabinet. With that said, how often does the DLM retrain itself? I've been resync-free for over a week now, unless it counts these PPP drops as "resyncs"?

For connection drops, Zen says "well, it's been fine for hours now - so nothing we can do"  Annoying... I like Zen, because although it sometimes takes a while to get them to action stuff, they do get it done and their support is solely UK based. However, working from home, this has become a nuisance and I need stable internet, so might consider switching (both phone and Internet) to someone else.

Thoughts/ideas/advice most welcome.

[Sheepie]

I do not believe BT for 1 second when they claim only a BT engineer can do DLM reset. That is what they want people to believe. Do you really think BT do not have remote access to their own equiptment!!

You have been banded, and it could take a long time for DLM to remove it. The best thing you can do is make sure your modem is left on and do not be tempted to try resync as it will only make it worse. I was banded and last resync was 11 days ago - still waiting for banding to be removed

[c6em]

I'd understood that the reasons for BT ensuring it did not have remote access was to equally ensure also that the equipment manufacturer (China) could also not get remote access.

[ejs]

The engineer performs the DLM reset remotely.

[spudgun]

Hi all,

So the original problem with copper joints has been fixed. However, following this, I have two more issues.

The first one is that because of this issue originally and many, many resyncs, I am now stuck on DLM band and cannot sync at more than 48998kbps (and it always syncs at that) despite attainable speed being close to 60Mbit.

The second one is that my connection still gets dropped occasionally, BUT... there's no resync. The sync never drops, just the PPP connection itself and I have to reauthenticate. Here's a typical log from my Billion router:

Code: [Select]

Dec 13 10:38:33 daemon notice syslog: pppd:No response to 2 echo-requests
Dec 13 10:38:33 daemon notice syslog: pppd:Serial link appears to be disconnected.
Dec 13 10:38:33 daemon crit syslog: Clear IP addresses.  PPP connection DOWN.
Dec 13 10:38:33 daemon crit syslog: Clear IP addresses.  Connection DOWN.
Dec 13 10:38:33 daemon notice syslog: pppd:Couldn't increase MTU to 1500.
Dec 13 10:38:33 daemon err syslog: pppd:Couldn't increase MRU to 1500
Dec 13 10:38:39 daemon notice syslog: pppd:Connection terminated.
Dec 13 10:38:39 daemon notice syslog: pppd:Connect time 77.4 minutes.
Dec 13 10:38:39 daemon notice syslog: pppd:Sent 27700040 bytes, received 143064778 bytes.
Dec 13 10:38:39 daemon notice syslog: pppd:Doing disconnect
Dec 13 10:38:42 daemon notice syslog: PPP: Start to connect ...
Dec 13 10:38:46 daemon crit syslog: PPP server detected.
Dec 13 10:38:46 daemon crit syslog: PPP session established.
Dec 13 10:38:46 daemon warn kernel: netdev path : ppp1.1 -> ptm0.1 -> ptm0
Dec 13 10:38:46 daemon notice syslog: pppd:Using interface ppp1.1
Dec 13 10:38:46 daemon notice syslog: pppd:Connect: ppp1.1 <--> ptm0.1
Dec 13 10:38:46 daemon notice syslog: pppd:Couldn't increase MTU to 1500.
Dec 13 10:38:46 daemon err syslog: pppd:Couldn't increase MRU to 1500
Dec 13 10:38:46 daemon err syslog: pppd:Couldn't increase MRU to 1500
Dec 13 10:38:46 daemon crit syslog: PPP LCP UP.
Dec 13 10:38:50 daemon notice syslog: pppd:Couldn't increase MTU to 1500.
Dec 13 10:38:50 daemon err syslog: pppd:Couldn't increase MRU to 1500
Dec 13 10:38:50 daemon err syslog: pppd:Couldn't increase MRU to 1500
Dec 13 10:38:50 daemon crit syslog: PPP LCP UP.
Dec 13 10:38:50 daemon notice syslog: pppd:Remote message: CHAP authentication success, unit 29300
Dec 13 10:38:50 daemon notice syslog: pppd:local  IP address x.x.x.x
Dec 13 10:38:50 daemon notice syslog: pppd:remote IP address 62.3.80.17
Dec 13 10:38:50 daemon notice syslog: pppd:primary   DNS address 212.23.6.100
Dec 13 10:38:50 daemon notice syslog: pppd:secondary DNS address 212.23.3.100
Dec 13 10:38:50 daemon crit syslog: Received valid IP address from server.  Connection UP.
Dec 13 10:38:54 daemon warn kernel: ^[[0;36;44mBroadcom Packet Flow Cache flushing the flows^[[0m
It normally happens in clusters over a few hours but can then be fine for days.

For both issues, Zen isn't interested in helping. I understand that they have no control over DLM and cannot reset it without sending an engineer to the exchange/cabinet. With that said, how often does the DLM retrain itself? I've been resync-free for over a week now, unless it counts these PPP drops as "resyncs"?

For connection drops, Zen says "well, it's been fine for hours now - so nothing we can do"  Annoying... I like Zen, because although it sometimes takes a while to get them to action stuff, they do get it done and their support is solely UK based. However, working from home, this has become a nuisance and I need stable internet, so might consider switching (both phone and Internet) to someone else.

Thoughts/ideas/advice most welcome.

My Billion router (8800AXL) would drop the PPP session on Zen just like you are describing above. I posted about it on the Billion forums and another user on Zen reported exactly the same thing. I've since switched to a HG612 + Router and the PPP session drops have gone

[Captain Jack]

My Billion router (8800AXL) would drop the PPP session on Zen just like you are describing above. I posted about it on the Billion forums and another user on Zen reported exactly the same thing. I've since switched to a HG612 + Router and the PPP session drops have gone

Wow, really? Strange as it has been stable for a good while and it's only recently that it started doing this.

I might have the 612 lying around somewhere - need to dig it out and flash it.

[Black Sheep]

The engineer performs the DLM reset remotely.

I suppose it boils down to what we are terming 'remotely' as ?? We 'remote access' the required system to perform the DLM reset (via mobile phone or laptop), but we are usually 'on-site' at the EU's premises when doing so.

The stipulation is that a DLM reset shouldn't be performed unless some form of fault or issue has been identified and resolved. There will always be grey areas .................. always. 

[Chrysalis]

The approach I would take is ask zen to see if the engineer did a DLM reset (we know he didnt), then from that it should be possible to book another engineer who's task will be to do the DLM reset, and he will have justification with the joint fault been fixed on the previous visit.

[Black Sheep]

The approach I would take is ask zen to see if the engineer did a DLM reset (we know he didnt), then from that it should be possible to book another engineer who's task will be to do the DLM reset, and he will have justification with the joint fault been fixed on the previous visit.

Absolutely right. It's not often we get tasks like these, but they do occur from time-to-time. Great for us, as we can fit a trip to the cafe in for a brew and a bacon butt, without going over our 'task time'. 

[Captain Jack]

The approach I would take is ask zen to see if the engineer did a DLM reset (we know he didnt), then from that it should be possible to book another engineer who's task will be to do the DLM reset, and he will have justification with the joint fault been fixed on the previous visit.

Sneaky. Thanks - will try this!