8800NL R2 becoming faulty or other reason

Apologies for bothering you.

My Fibre1 service has been pretty stable until this last week. On Thursday evening we lost connectivity. The 8800NL R2 logs showed repeated attempts to establish a connection. After several attempts, I restarted the R2 and it connected. The link was lost yesterday around 5pm and new IP issued. Today, from the truncated log it looks like the connection was lost around midday and again at 15:39. The latter didn't result in a new IP being issued. Downstream rate has dropped a little to 47570.

I guess electronics do fail, so maybe I need to unpack the Hub2 to see if it improves the reliability. A quiet line test shows a quiet line.

The end of the log for midday shows

Apr 2 12:06:10 daemon notice syslog: pppd:local IP address 86.190.xx.188
Apr 2 12:06:10 daemon notice syslog: pppd:remote IP address 172.16.xx.103
Apr 2 12:06:10 daemon notice syslog: pppd:primary DNS address 81.139.56.100
Apr 2 12:06:10 daemon notice syslog: pppd:secondary DNS address 81.139.57.100
Apr 2 12:06:10 daemon crit syslog: Received valid IP address from server. Connection UP.

And for 15:39

Apr 2 15:39:51 kern warn kernel: bcmxtmcfg: SILI Start - UtopiaCfg - 10
Apr 2 15:39:51 kern warn kernel: bcmxtmcfg: XTM Link Information, port = 0, State = DOWN(2), Service Support = PTM(2)
Apr 2 15:39:51 kern warn kernel: Calling SetLinkInfo 1
Apr 2 15:39:51 kern warn kernel: HOST XTM tx ch 0 disabled.
Apr 2 15:39:51 kern warn kernel: W1B -353450680
Apr 2 15:39:51 kern warn kernel: W1E -353450678
Apr 2 15:39:51 kern warn kernel: bcmxtmcfg: Connection DOWN, LinkActiveStatus=0x0
Apr 2 15:39:51 kern warn kernel: bcmxtmcfg: ReconfigureSAR port 0 traffictype 0
Apr 2 15:39:51 kern warn kernel: bcmxtmcfg: SILI End - UtopiaCfg - 0
Apr 2 15:39:51 kern warn kernel: bcmxtmcfg: DS xDSL G.inp Mode = DISABLED
Apr 2 15:39:51 kern warn kernel: bcmxtmcfg: xDSL G.Fast Mode = DISABLED
Apr 2 15:39:51 kern warn kernel: Warning: SAR Channel 0 Rx Bogus Event
Apr 2 15:39:53 daemon notice syslog: pppd:Terminating on signal 20.
Apr 2 15:39:54 daemon crit syslog: Clear IP addresses. PPP connection DOWN.
Apr 2 15:39:54 daemon crit syslog: Clear IP addresses. Connection DOWN.

.......

Apr 2 15:40:47 daemon notice syslog: pppd:local IP address 86.190.xx.188
Apr 2 15:40:47 daemon notice syslog: pppd:remote IP address 172.16.xx.103
Apr 2 15:40:47 daemon notice syslog: pppd:primary DNS address 81.139.57.100
Apr 2 15:40:47 daemon notice syslog: pppd:secondary DNS address 81.139.56.100
Apr 2 15:40:47 daemon crit syslog: Received valid IP address from server. Connection UP.


DSLstats shows this summary.

DSLAM type / SW version: BDCM:0xc190 (193.144) / v0xc190
Modem/router firmware: AnnexA version - A2pvI042j1.d26q_rc1a
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 0 hour 39 min 30 sec
Resyncs: 0 (since 02 Apr 2022 15:45:21)

Downstream Upstream
Line attenuation (dB): 21.6 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 47570 9998
SNR margin (dB): 5.6 6.2
Power (dBm): 11.9 7.5
Interleave depth: 8 1
INP: 49.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)

RSCorr/RS (%): 0.0525 0.0019
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 13.7 8.57

Do the figures suggest a problem with the line? The 8800 has only been up for 1 day 20 hours.

Regards

Paul

In reply to a post by BarkingMad:

Do the figures suggest a problem with the line? The 8800 has only been up for 1 day 20 hours.

Not really. They look okay for the chipset in use.

Sync speed is about right for the attenuation.
SNRM is healthy. G.INP enabled on the downstream.

The ES numbers are a little higher than could be hoped for for a line running G.INP but I would put that down to the budget Broadcom chipset used in the 8800NL R2.

The previous R1 model had a flagship Broadcom chipset and would no doubt have given lower error numbers and a higher sync.

Nothing to worry about from the DSL stats at least.

Thanks j0hn83,

I did notice this on BQM some weeks ago which I hadn't seen before on my line.

My Broadband Ping

The BQM web page says this was pattern was likely to a core network problem.

Perhaps the R2 has developed a fault. I'll ready the Hub2 in case my wife comments that the disconnects are impacting her work.

I believe the Hub2 will support digital voice (DV) but do you have any alternative hardware that would be DV capable. I'm not sure what we will do with voice in the future. The line is only used for incoming calls and it looks like BT has introduced a PAYG call plan which has a monthly charge. Perhaps we will dump the voice or try to move it to a different provider. I was hoping someone on tb would have produced a blog to help the uneducated.

Thanks again,

Paul

The charge for PAYG was clarified on a BT Consumer forum recently, there is no charge for the PAYG calls plan, but there is a charge , between £2 and £5 for having a phone service associated with the broadband service …basically if you want a phone number , incoming calls , and the possibility of making emergency calls it costs £2 to £5 , if you take this option, a calls plan is compulsory, the cheapest is the ‘free’ PAYG plan, where calls are charged for on a per call basis, so if you don’t make any calls , no more charges, ….but obviously you are paying £2 -£5 more than someone who has standalone broadband , but those customers don’t have the option of making or receiving any calls including emergency calls

Edited by Iniltous (Sun 03-Apr-22 09:53:01)

I think the confusing is that what many have had for the last 50+ years (and has always been the norm) has now been given a name of 'PAYG' whereas inclusive call packages have had their own various names since their inception.

This is true.

What is also true is that on mobile phones, on most services PAYG long ago ceased to be what it claims to be. It has become monthly contract with remaining balance lost if not used in the month.

It's time for Ofcom or the ASA to define it.

Thanks all for the clarification on the new PAYG calling plan.

I've put the SH2 on the line on Sunday and apart from overnight resyncs/firmware updates we haven't seen any syncs during the day so far. It syncs a little lower on the downstream.