Print

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

[splbound]

Crappy connections are back with my Zen FTTC. Had a good run for a few months but going from my MWDS stats something kicked off on the 6th April.

What happens during these disconnections:

1) 100% packet loss starts which I can see on my TBB graphs..
2) I see a medium to large SNRM dip on my DSLSTATS server.
3) After a few seconds the Billion 7800DX handling the PPP connection detects no response to 3 echo requests "daemon notice syslog: pppd:No response to 3 echo-requests". From this it determines that the link is down so disconnects and re-establises the PPP link. It does not take long for the 7800DX to re-establish the PPP connection and does so without error.
4) During all this time the HG612 does not lose sync!

This happens multiple times midday and late night/early morning.
It's driving me insane especially during the day where I remote in from work.

I have already contacted Zen. They suggest a factory Reset HG612 to stock locked version and run the setup for 24 hours to see if I still get problems. My crystal ball tells me that this will no absolutely nothing to fix it. I'll do it anyways after I collect more details\stats just to appease Zen support. I'll also try my old 7800N on the connection just to rule out the router going bad.

Not sure how it is possible to have PPP loss, 100% packet loss and a big SNRM drop without the HG612 line sync dropping? I would assume if it was interference that the HG612 sync would drop?

Anyone have any ideas on whether it is actually the line or some equipment down the line equipment going faulty. Nothing has changed on my end, phone line wise or equipment wise. It has been pretty good before the 6th April. I would happily give up sync speed for a rock stable connection.

My stats are on MWDS under splbound to see the roller coaster ride of my SNRM db.
MWDS does not show the major drops as it cannot log it when the PPP is down. DSLSTATS on the server show the true story and it ain't pretty.

[loonylion]

I agree that reflashing the hg612 will likely do nothing. It's either the router or something at the other end

[kitz]

I see a medium to large SNRM dip on my DSLSTATS server.

This could be the cause of your packet loss

pppd:No response to 3 echo-requests

This concerns me, your router is detecting no traffic and dropping the connection.
If the lack of SNRm causes packet loss.. and if some of that packet loss are the echo-requests which check to see if your line isn't idle.  Then it suspects that the line is idle then it drops the PPP session. 
   
I dont know enough about the config & echo requests to be able to answer your question, but it suggests to me its something in the config needs changing. 

[kitz]

Just been doing a wee bit more digging as it intrigued me.

As suspected from wiki

The role of pppd is managing PPP session establishment and session termination. During session establishment, pppd has the role of:
Looped link detection: PPP detects looped links using magic numbers. When PPPD sends PPP LCP messages, these messages include a magic number. If a line is looped, the node receives an LCP message with its own magic number, instead of getting a message with the peer's magic number.

../snip/..

pppd terminates a PPP link when:
the link is considered "idle" (if configured)

I then came across this
http://www.billion.uk.com/forum/viewtopic.php?f=18&t=3081

which again implies that as suspected the connection is dropping because its not receiving a response to the echo requests.   Im afraid that still doesnt help you completely, because you really need to configure the router so it doesnt drop so readily.
It does give a clue for the params which possibly need to be configured though.

[WWWombat]

I don't think pppd is dropping the connection because it thinks it is idle - which I understand to really mean that there is no user traffic inbound or outbound - which, in turn, I think means there is no traffic to/from the higher layers in the stack (which means IP).

I thought that the echo-requests' job is to check the other end of the link is still there, and aren't part of "traffic" in that sense - the packets stay purely within layer 2, checking that the two layer 2 entities can communicate. Not a keep-alive (certainly), but more like a "check-alive".

If the other end of the point-to-point link is no longer responding, pppd's only measure is to take down the existing ppp connection, and establish a new one.

Obviously severe packet loss at layer 1 (ie the DSL layer) will make layer 2 think it is no longer able to communicate with it's peer - either because the echo requests go missing, or the responses go missing. At the same time, it will have had no indication from layer 1 of a failure (ie a resync), so all it can do is disconnect and start again...

The question for the OP is in stage 3. Does the DSL link suddenly stop losing packets, and fully regain SNR, as soon as pppd attempts to make a new connection? Always? Repeatedly, without exception?

If so, something very wrong is going on with the modem.

Note that the modem could well be keeping sync when SNRM drops. I've seen it happen down to around 1dB, but it ought to resync if the SNRM reached 0dB.

[kitz]

Ah thank you for the clarification wombat.
I admitted in my post that I didnt know much about pppd and echo cancellation, but I wanted to set the ball in motion that something was going wrong in that particular area.

If the other end of the point-to-point link is no longer responding, pppd's only measure is to take down the existing ppp connection, and establish a new one.

So could the (layer 2) packet loss symptoms also cause the same 'check alive' to fail?

pppd's only measure is to take down the existing ppp connection, and establish a new one.

This is obviously what is happening - sync is still there and maintained.

[splbound]

Thanks for the help and insight!

The question for the OP is in stage 3. Does the DSL link suddenly stop losing packets, and fully regain SNR, as soon as pppd attempts to make a new connection? Always? Repeatedly, without exception?

If so, something very wrong is going on with the modem.

I have attached more details of this particular drop which happens around the same time 1pm every day.
- Detailed SNR direct from DSLstats.
- Think Broadband Ping graphs around that period
- System log files from the Billion Router (timestamps are out by an hour as it is in GMT)

I cannot really say with the resolution of the data I have from the TBB ping graphs. Total packet loss looks like it coincides with PPP reconnection.
The billion log files always always show one re-attempt at PPP reconnection which always reconnects.

The disruption duration looks very short, more spike like. Probably the reason why sync remains intact.
When PPP does attempt a reconnect the SNR has already recovered.

Looks like the PPP Layer 2 does not recover after the spike.
Maybe given more time it may be possible for the layer to recover by itself always catches the outage by not detecting the pppd echo requests.

Note that the modem could well be keeping sync when SNRM drops. I've seen it happen down to around 1dB, but it ought to resync if the SNRM reached 0dB.

Thank you, good to know it looks like that SNR margin does not drop that low for these PPP outages I am having.
The actual re-syncs are accompanied by spikes that drop well below 1db.

Would it be worth trying the connection with another HG612?
My other modem is an ECI and I would like to avoid spending £50 for another HG612.

Looks line a case of SHINE the more I look at it now. It just has me perplexes that the modem still keeps a sync thorough it. Makes it harder to raise a case with openreach and ZEN if their systems detect that the line up and fine.

[splbound]

I have now acquired a spare HG612 rev 2B though. Forgot to check in the auction but the 2B should be fine with the 1Amp PSU from the 3B. Looking to test it on my line next week after I upgrade it to the latest firmware.

[kitz]

It does possibly look like it could be shine causing the issue, although the increases slight increases in SNRm before the spikes are also noted.    Out of interest does the SNRm spike if the landline rings, or during a phone call?

It just has me perplexes that the modem still keeps a sync thorough it.

In the past Ive seen modem/routers that will actually hang on below 0dB (the old DG834 models).   The thing is its the HG612 which is controlling the sync and the Billion controlling the PPP session.

Sync is maintained by having sufficient SNR to carry a signal on the copper between the dslam in the cab and modem.  Sync doesn't immediately drop when signal is lost..  the modem enters an alarm state for a while before initiating a full resync - See LOS.
The modem may not even get LOS, it may just produce ES or SES, these are packets which have been lost but later retransmitted.


OTOH PPP is maintained by the router and is between the Billion and your ISP and done at a different layer.  I will re-iterate that I dont know enough about how the echo requests work,  but to me it implies that something somewhere during that period meaning that the router and ISP can communicate.  The router senses this and drops the connection.

When I mentioned config in my earlier posts, I wondered if it was possible to increase the amount of echo requests before the router determines that the link is dead.

I can fully understand why the line stays in sync - as wombat said thats Layer 1 which is physical layer.
I can sort of understand why the PPP session is dropping, but I dont know  enough about layer 2 or layer 4 as its >10yrs ago that I did the OSI stuff and I've forgotten most of it now, so Im not about to even attempt to bluff my way through it

[boost]

I'm not sure I would be overly concerned?

The HG is doing a sterling job of keeping the line up and PPPd is detecting issues and forcing a reauth.

You may want to check if the HG is registering Loss Of Margin/Framing errors or similar, which would be the proof it's the underlying conditions and not PPP or the HG

[burakkucat]

Just one datum point with regards to the HG612.

I have witnessed one holding onto synchronisation with the MSAN right down to a SNR of -1.9 dB. The throughput was utterly hopeless, to all intents and purposes non-existent . . .

[Bald_Eagle1]

Just one datum point with regards to the HG612.

I have also seen that via my HG612, back in the 11 month 'dark' period when I had an intermittent external D-side cable joint fault.

[boost]

Cisco, although hapless in the DSL market, have a client side config option to force a resynch when x loss of margin messages are received. It's disabled by default.

I wonder if the HG has a similar parameter?

[splbound]

Thanks all again for your insight.

It does possibly look like it could be shine causing the issue, although the increases slight increases in SNRm before the spikes are also noted.    Out of interest does the SNRm spike if the landline rings, or during a phone call?

I really do think it's a SHINE issue. It has got a little better for the past two days, bit nothing like the weeks+ of continuous connection I had before.

Not much I can do with having the Billion require more PPP echo's before it does a disconnect/reconnect cycle.
100% packet loss occurs during this time anyway so I doubt the PPP connection will recover.
Increasing the wait for more PPP echo's will just add to the outage time.

I'm not sure I would be overly concerned?

The HG is doing a sterling job of keeping the line up and PPPd is detecting issues and forcing a reauth.

You may want to check if the HG is registering Loss Of Margin/Framing errors or similar, which would be the proof it's the underlying conditions and not PPP or the HG

When the HG does resync it reports it as due to  RDI: Remote Defect Indicator/DLM.
The last LOS reported was when I unplugged the unit to reroute the power cable so that was due to me.

I concur that the HG is doing a sterling job at keeping sync and looks like my issue is with the PPP layer.

If only these disconnections didn't affect me during the day when I work remoted into my home network, I would let it slide.
I used to get connection uptimes in the realm of 100+ hours. Looking back at my stats in Nov 2014 I managed one for around 615 hours. Now I'm lucky if I can even manage 24.

Looking at the uptime trends, my max uptimes have been slowly declining since March 2015.

I'll sit on the existing setup for a while longer. I'm hoping that the disturbance is going away as the uptime's have been been getting longer these past two days.

Thanks all again for your help.

[Ragnarok]

On the odd very rare occasion I've had to reboot the modem( and router too for good measure) to regain full connectivity, weird ppp anomalies. I've had this happen twice when using the HG612. BCM chips are renowned for clinging on to a sync for dear life.

The only time I've seen wild SNR swings what when my cable cluster was in a flooded under ground duct, and in ill health, and wide open to accepting the noise from my next door neighbours dodgy equipment and local crosstalk.

Since BT fixed the underground cable and duct it rejects the noise alot better and reduced the effect of local crosstalk.