[OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)

Thu Nov 20 15:49:54 EST 2014

Hi Jaime,

not an expert on adel modem errors, let alone lantiq, here is my attempt at helping out:

On Nov 20, 2014, at 17:26 , Jaime T <enopatch at gmail.com> wrote:

> On 17 November 2014 18:36, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> Hi Jaime,
>> maybe you should also look at the rror counters. Especially the CRC and HEC errors short before the connection drops might be interesting.
>> Best Regards
>>        Sebastian
> 
> Hi everyone.
> 
> I've set lcp-echo-failure to "10" and lcp-echo-interval to "3" and I'm
> still getting the disconnections. The logs fill with the following
> now:
> 
> Thu Nov 20 15:29:55 2014 kern.warn kernel: [15746.372000] leave showtime

	Ooops, the modem somehow lost ist DSL connection to the DSLAM

> Thu Nov 20 15:29:56 2014 daemon.info pppd[7651]: Terminating on signal 15
> Thu Nov 20 15:29:56 2014 daemon.info pppd[7651]: Connect time 6.0 minutes.
> Thu Nov 20 15:29:56 2014 daemon.info pppd[7651]: Sent 89186 bytes,
> received 46470 bytes.
> Thu Nov 20 15:29:56 2014 daemon.notice netifd: Network device
> 'pppoa-wan' link is down
> Thu Nov 20 15:30:01 2014 daemon.notice netifd: Interface 'wan' is now down
> Thu Nov 20 15:30:11 2014 daemon.warn dnsmasq[1503]: no servers found
> in /tmp/resolv.conf.auto, will retry
> Thu Nov 20 15:30:24 2014 kern.err kernel: [15775.136000]
> [DSL_BSP_Showtime 894]: Datarate US intl = 924903, fast = 0
> Thu Nov 20 15:30:24 2014 kern.warn kernel: [15775.140000] enter
> showtime, cell rate: 0 - 2181, 1 - 2181, xdata addr: 0x82e90000

This looks like the modem just entered showtime (basically you can only transfer data in showtime, so the was a loss of the DSL link as well as the PPP link that sits on top of it) I would guess the DSL link  went away from under the PPP connection so PPPD was forced to exit as well.

> Thu Nov 20 15:30:26 2014 daemon.notice netifd: Interface 'wan' is setting up now
> Thu Nov 20 15:30:26 2014 daemon.info pppd[7835]: Plugin pppoatm.so loaded.
> Thu Nov 20 15:30:26 2014 daemon.info pppd[7835]: PPPoATM plugin_init
> Thu Nov 20 15:30:26 2014 daemon.info pppd[7835]: PPPoATM
> setdevname_pppoatm - SUCCESS:0.38
> Thu Nov 20 15:30:26 2014 daemon.notice pppd[7835]: pppd 2.4.7 started
> by root, uid 0
> Thu Nov 20 15:30:26 2014 daemon.info pppd[7835]: Using interface pppoa-wan
> 
> Perhaps the "lcp echo request" thing just be a red herring caused by
> the dsl link losing sync?

	I agree with that interpretation.

> 
> I've also tried to find some info on how to get the error counters out
> for the lantiq dsl connection (using dsl_cpe_control), and the best
> info I can get hold of is:
> 
> pmcctg 0 0
> nReturn=15 nChannel=0 nDirection=0 nElapsedTime=18031 bValid=1
> nCodeViolations=14662 nFEC=5910810

code violations are caused by CRC errors of transmitted packets, these require retransmission from sender to receiver (these are bad as they cost bandwidth). FEC is forward error correction (basically reed salomon code with potential interleaving of cells to spread out error bursts). The elapsed time I assume to be in seconds so ~5 hours … and 14662/18031 = 0.81 errors per second, quite a lot...

> 
> pmdpctg 0 0
> nReturn=15 nChannel=0 nDirection=0 nElapsedTime=18058 bValid=1
> nHEC=10735 nTotalCells=256128475 nUserTotalCells=1896600 nIBE=0
> nTxUserTotalCells=0 nTxIBE=0
> 
> pmlsc1dg 0 0
> nReturn=15 nDirection=0 nHistoryInterval=0 nElapsedTime=58145 bValid=1
> nES=432

	These are errored seconds a count of the seconds with CRC errors (multiple CRCs per second will just increase ES by one so it removes bursty errors to some degree from the statistics), if elapsed time is in seconds the ES accumulated inside of ~16 hours.

> nSES=256 nLOSS=22 nUAS=2433 nLOFS=1868

	SES means severely errored seconds (not sure how they are counted, but they typically increase way slower than ES), 	• UAS: Unavailable Seconds - Seconds where you had no sync (from http://en.wikipedia.org/wiki/G.992.1) this most likely is the culprit for your pop to go away. I do not know whether you can make pop wait long enough for your line to resync so your pppd disconnects would go away, but I also do not know whether your ISP would allow that since their PPPD also sees you go and might not allow to reconnect but enforce a new connection (I have no clue at all). Also I think you should try to improve the quality of the DSL link to make the PPP issue rare enough o just ignore it.

> 
> The problem I now have is that I don't know how to interpret these
> results: are they good, or bad? (And do they explain why I'm getting
> dozens of disconnections every day?)

	I think they record your disconnects, but not necessarily tell you what caused the del link to go out for lunch...

> 
> Does anyone know if I can force a slower/lower connection speed from
> my side? (I would happily sacrifice some speed for more stability!)

	Maybe https://forum.openwrt.org/viewtopic.php?pid=222065 works for you? Increasing the SNR ,arhin should make your link more resilient...

> If
> not, I'm going to have to buy a dsl modem with a broadcom chipset and
> use that instead…

	If you could buy such a modem you could test whether it really improves things? If there is a massive source of RF ingress on your link maybe another odem might not help much?

Best Regards
	Sebastian

> 
> J :-)
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel