Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Captain Jack on November 22, 2016, 10:37:55 AM
-
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):
> 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.
> 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
-
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
-
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?
-
I had Zen run the line test again and they are now getting "impairment in copper joint" fault back.
-
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.
-
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:
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.
-
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 :(
-
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.
-
The engineer performs the DLM reset remotely.
-
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:
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
-
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.
-
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. :)
-
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.
-
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'. ;) :)
-
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!
-
Well that didn't go well.
I've looked at your connection and can see that the 49m profile is still applied on your line which is what is limiting your sync speed. However the profile is also labelled as retransmission high, this means that it is seeing errors on the line and having to retransmit the data frequently. As this is the case the DLM will likely not remove the profile as your line would not be stable at the higher speeds. The job of the DLM is to make sure the line stays stable therefore it is doing its job correctly by not removing the profile.
BT estimates that your line is capable of about 35mbps but with a range of acceptable speeds being 20.3m to 48.7m. At the moment you are already exceeding the expectations of what the line is capable of. As your sync speeds are above estimate for the line we would not consider this a fault condition and not look at requesting BT do a DLM reset.
Seems like a reasonable response but I have a feeling my line is capable of more...
-
zen's attitude lately to faults has been poor from what I read over the net, not good considering the price of the isp.
Send a polite request to action your request. I dont know what you said to get that answer but you need to explain the profile is only like that because of the line before the fault got fixed.
-
Well that didn't go well.
Seems like a reasonable response but I have a feeling my line is capable of more...
Yea you can see where he is coming from. They must get loads of people who give them the "my line use to get much more speed than its getting now" bullshine to try and get more speed.
However in your case it is not bullshine. If it were me i would send a polite email back just to reinforce the fact that you know your line is capable of getting a better speed and you believe the profile is wrong and was a manual intervention to fix it. (more on this below)
Forgive me if this is wrong but it might be of some use to you... once on an ADSL line we also had a lowered profile after bad weather and after a number of weeks the profile did not increase. After many weeks of complaining and not dropping the issue with BT, they had an engineer manually adjust the profile and called the service "manual intervention" or something like that. It was back to normal ever since. Now i am not sure if this can be done with FTTC but surely they can just bring your profile up and if the errors start happening again then the worst it will do is just lower again?
Hope you get this fixed in any case!
J