FEC and CRC errors - high numbers of UP errors

[#1]

Can anyone comment on the huge numbers of FEC and CRC errors up that my Thomson 585 is reporting please?
This has only started happening over the past few months.
Are they important?
Details:
DSL Connection 
Link Information
   

Uptime: 0 days, 3:24:23

DSL Type: G.992.5 annex A

Bandwidth (Up/Down) [kbps/kbps]: 444 / 8,032

Data Transferred (Sent/Received) [kB/kB]: 0.00 / 0.00

Output Power (Up/Down) [dBm]: 12.5 / 0.0

Line Attenuation (Up/Down) [dB]: 15.5 / 31.5

SN Margin (Up/Down) [dB]: 27.5 / 15.0

Vendor ID (Local/Remote): TMMB / IFTN

Loss of Framing (Local/Remote): 0 / 0

Loss of Signal (Local/Remote): 0 / 0

Loss of Power (Local/Remote): 0 / 0

Loss of Link (Remote): 0

Error Seconds (Local/Remote): 1 / 0

FEC Errors (Up/Down): 4,294,967,264 / 69,837

CRC Errors (Up/Down): 4,294,967,264 / 126

HEC Errors (Up/Down): 0 / 117

[#2]

This volume of Upstream errors is a typical symtom of noise on the line, specifically a likely unfiltered telephone device including phones, faxes, filters poorer quality internal cables and the more famous one as it is commonly forgotten, the Sky box.
Along side if, if you have a alarm system attached to this line, it worthwhile contacting your alarm provider to enquire if they attached a broadband filter as part of its installation.

[#3]

That number of upstream FEC and CRC errors is one of the "magic numbers" that the Thomson router frequently appears to make up when turned on, There is no way that number of errors has accumulated in 3 hours, and if the count were real the value would change significantly every time the stats were displayed. I assume those large numbers remains constant.
Does it matter? Probably not. Resetting the router to factory defaults and starting set-up again might get rid of them, simple restarting often seems not to.
For the mathematically minded the number represents an unsigned 32-bit binary number consisting of 1s in all but the 5 least significant bits. It looks like some sort of mask that gets stored in the wrong place.

[#4]

One of my Thompson routers routinely comes up with what looks like those exact figures. Usually just after boot up.
It must be fiction as the figures never increase.

[#5]

Thanks for your comments.
I discovered that, most times, the modem booted up with zero FEC and CRC UP errors, but within 7 or 8 minutes, either this number 4,294,967,264 or something very much like it, suddenly appeared.
Usually, it remained constant, but occasionally it incremented very very slowly, far less slowly than DOWN errors.
I tried new filters all round, unplugging all other devices, using only the BT test socket etc to no effect; the number still appeared.
I’m talking in the past tense because it seems to be fixed now.
I had already removed the orange and white wire from the main telephone terminal 3 but in desperation I then also removed it from all other telephone extension sockets in use.
So it seems to have been caused by local noise from these wires, in the absence of any other explanation.
My latest stats are:
Link Information
Uptime: 0 days, 11:35:14
DSL Type: G.992.5 annex A
Bandwidth (Up/Down) [kbps/kbps]: 444 / 6,655
Data Transferred (Sent/Received) [kB/kB]: 0.00 / 0.00
Output Power (Up/Down) [dBm]: 12.5 / 0.0
Line Attenuation (Up/Down) [dB]: 15.5 / 31.5
SN Margin (Up/Down) [dB]: 27.5 / 14.5
Vendor ID (Local/Remote): TMMB / IFTN
Loss of Framing (Local/Remote): 11 / 0
Loss of Signal (Local/Remote): 1 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 2 / 0
FEC Errors (Up/Down): 0 / 116,708
CRC Errors (Up/Down): 0 / 182
HEC Errors (Up/Down): 0 / 137
jim:green post compacted to make it easier to read without scrolling mod:end

[#6]

Glad to hear you managed to stop this happening, and removing all bell wiring is definitely a good move.
Looking at your stats, I think the DLM has responded to the connection drops/re-starts you've done recently by putting you on a banded profile which is restricting your downstream sync speed. Given a few days (perhaps 7 or 14) with a solid connection the DLM might remove that. Otherwise, since you've improved your wiring Plusnet might agree to request its removal if your connection holds steady over the weekend.
Main thing, don't restart the router, or the timer rests.

[#7]

I spoke too soon about my problem being resolved!
Yes, my download speed is now significantly lower and although I have avoided re-booting the router (as advised by spraxyt), I noticed from the Event Log that it lost connection all by itself overnight on March 10th, again on 11th and again during the day on 12th.
It’s managed to stay connected for just over a day, but those billions of alleged FEC and CRC UP errors re-appeared last time it re-connected, as shown below.
There are also entries in local Loss of Framing, Loss of Signal, and Error Seconds, which I cannot recall seeing before, and don’t understand. Are they relevant and/or important?
The Event Log is also shown below, from the time it last re-connected, with the SNTP entries removed for clarity.
There are a lot of red Firewall entries – does this indicate a problem?
Are any of the other entries unusual?
Do I need a new router?
Details of my router:
Product Name: TG585 v7
Serial Number: CP0902TFJR8
Software Release: 7.4.4.7
Software Variant: DX
Boot Loader Version: 1.0.0
Product Code: 36588280
Board Name: CANT-P
As you may realise, my knowledge is limited, so any guidance will be gratefully received.
Link Information @17.50 March 13th 2011
Uptime: 1 day, 3:02:08
DSL Type: G.992.5 annex A
Bandwidth (Up/Down) [kbps/kbps]: 444 / 6,655
Data Transferred (Sent/Received) [kB/kB]: 0.00 / 0.00
Output Power (Up/Down) [dBm]: 12.5 / 0.0
Line Attenuation (Up/Down) [dB]: 15.5 / 31.5
SN Margin (Up/Down) [dB]: 28.0 / 16.0
Vendor ID (Local/Remote): TMMB / IFTN
Loss of Framing (Local/Remote): 33 / 0
Loss of Signal (Local/Remote): 3 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 4 / 0
FEC Errors (Up/Down): 4,294,967,264 / 349,841
CRC Errors (Up/Down): 4,294,967,264 / 225
HEC Errors (Up/Down): 0 / 162
Event Log @ 17.50 March 13th 2011 (with SNTP entries removed)
Mar 13 09:22:17 FIREWALL icmp check (1 of 1): Protocol: ICMP Src ip: 81.168.72.28 Dst ip: 91.125.146.115 Type: Destination Unreachable Code: Host Unreacheable
Mar 13 09:21:27 IDS proto parser : tcp data on syn segment (1 of 1) : 91.205.41.75 91.125.146.115 0040 TCP 80->47950 [S.A...] seq 2474576388 ack 2474206279 win 473
Mar 13 08:51:50 IDS proto parser : tcp data on syn segment (1 of 1) : 91.205.41.75 91.125.146.115 0040 TCP 80->19447 [S.A...] seq 449078533 ack 1111391598 win 1327
Mar 13 08:43:00 FIREWALL icmp check (1 of 1): Protocol: ICMP Src ip: 81.168.72.28 Dst ip: 91.125.146.115 Type: Destination Unreachable Code: Host Unreacheable
Mar 13 08:36:40 FIREWALL icmp check (1 of 3): Protocol: ICMP Src ip: 81.168.72.28 Dst ip: 91.125.146.115 Type: Destination Unreachable Code: Host Unreacheable
Mar 13 08:28:58 FIREWALL icmp check (1 of 1): Protocol: ICMP Src ip: 81.168.72.28 Dst ip: 91.125.146.115 Type: Destination Unreachable Code: Host Unreacheable
Mar 13 08:26:42 FIREWALL icmp check (1 of 5): Protocol: ICMP Src ip: 81.168.72.28 Dst ip: 91.125.146.115 Type: Destination Unreachable Code: Host Unreacheable
Mar 13 08:25:28 FIREWALL icmp check (1 of 1): Protocol: ICMP Src ip: 81.168.72.28 Dst ip: 91.125.146.115 Type: Destination Unreachable Code: Host Unreacheable
Mar 13 06:18:32 FIREWALL icmp check (1 of 2): Protocol: ICMP Src ip: 61.185.14.36 Dst ip: 91.125.146.115 Type: Destination Unreachable Code: Port Unreacheable
Mar 13 05:47:17 IDS proto parser : tcp data on syn segment (1 of 1) : 91.205.41.75 91.125.146.115 0040 TCP 80->47688 [S.A...] seq 4223414789 ack 3745464505 win 48
Mar 12 21:21:21 FIREWALL icmp check (1 of 1): Protocol: ICMP Src ip: 81.168.72.28 Dst ip: 91.125.146.115 Type: Destination Unreachable Code: Host Unreacheable
Mar 12 21:00:11 IDS proto parser : tcp data on syn segment (1 of 1) : 91.205.41.75 91.125.146.115 0040 TCP 80->63936 [S.A...] seq 3982764549 ack 615020185 win 1186
Mar 12 14:45:59 GRP Default destination is routed via gateway 91.125.146.115
Mar 12 14:45:59 PPP link up (Internet) [91.125.146.115]
Mar 12 14:45:59 PPP CHAP Chap receive success : authentication ok
Mar 12 14:45:59 PPP CHAP Receive challenge (rhost = pcl-ag06)
Mar 12 14:45:58 PPP CHAP Receive challenge (rhost = bras-red1.bs)
Mar 12 14:45:42 GRP Default destination is not routed anymore via gateway 87.113.180.38
Mar 12 14:45:42 PPP link down (Internet) [87.113.180.38]
Mar 12 14:45:35 FIREWALL event (1 of 1): deleted rules
Mar 12 14:45:35 GRP Default destination is routed via gateway 87.113.180.38
Mar 12 14:45:35 xDSL linestate up (ITU-T G.992.5; downstream: 6655 kbit/s, upstream: 444 kbit/s; output Power Down: 20.5 dBm, Up: 12.5 dBm; line Attenuation Down: 31.5 dB, Up: 15.5 dB; snr Margin Down: 16.5 dB, Up: 28.0 dB)
Mar 12 14:45:10 xDSL linestate down
jim:green post compacted to make it easier to follow mod:end

[#8]

Do you have an alternative router you could try to see if the disconnection/restart/line errors problem goes away? Your current one does appear to be showing symptoms of imminent failure.
The Firewall and IDS proto parser records are not an error indication, those are intrusion attempts and your router is blocking them - as it should. See this thread for more on the IDS proto parser entries (the source of yours is the same). The Firewall entries are via an ISP based in Exeter, and via one based in China.

[#9]

As suggested, I swapped to another TG585 router, and relocated it well away from anything electrical, adjacent to the main BT socket, which has also been fitted with an adsl faceplate.
(The bell wire is also disconnected, as previously mentioned.)
The combination of the earlier router problems and my ’fiddling about’ trying to fix things resulted in  my IP profile being reduced, my synch speed being restricted by banding and my download speed reducing to less than 50% of what it was.
The new router appears to be stable and I haven’t seen any unexpected adsl linestate down entries in the Events Log since the router was changed.
Also, far fewer FEC/CRC/HEC Down errors are now being reported – see below.
(The weird fictitious number of FEC/CRC Up errors only appeared again when I tried a re-boot two days ago to try to achieve a higher synch; until then the Up errors were zero.)
Over the past few days my download speed has increased to about 80% of what it was (now around 5000kbps) and my IP profile has been raised a bit (but nowhere near its previous level) but synching is still banded.
How long will it be until banding will be removed and I can try another re-boot?
From memory, it used to synch in excess of 8000.
spraxyt suggested that banding could be removed soon?
I’ve also been doing frequent ping tests since changing the router and the ‘A’ result attached is typical.
Link Information @ 23rd March 2011
Uptime: 1 day, 13:53:17
DSL Type: G.992.5 annex A
Bandwidth (Up/Down) [kbps/kbps]: 443 / 6,656
Data Transferred (Sent/Received) [kB/kB]: 0.00 / 0.00
Output Power (Up/Down) [dBm]: 12.5 / 0.0
Line Attenuation (Up/Down) [dB]: 15.5 / 31.0
SN Margin (Up/Down) [dB]: 29.5 / 16.0
Vendor ID (Local/Remote): TMMB / IFTN
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 2 / 0
FEC Errors (Up/Down): 4,294,967,201 / 0
CRC Errors (Up/Down): 4,294,967,201 / 2,327
HEC Errors (Up/Down): 0 / 1,465

[#10]

By tomorrow morning you should have 2 days with stable connection. I think Plusnet like to see three days after an equipment change before considering requesting the removal of banding. However hopefully they'll pop in here tomorrow and let you know how it looks to them.
When/if banding is removed your router should restart automatically, so no need to do that yourself. The resulting sync speed increase is likely to give higher CRC/HEC error rates, and the DLM might increase target noise margin to compensate. This would reduce sync speed a little, however hopefully no return to a banded profile.

[#11]

My connection is now very stable but I'm still banded at 6656 with a profile of 5500.
I would appreciate it very much if a kind Plusnet person reading this could now investigate and remove the restrictions.
Or, do I need to raise a ticket?
Many thanks, particularly to you spraxyt.

[#12]

Hi Bazman,
I've just requested an SNR reset for you, that should sort things out. Latest connection is over 4 days now so we should be all good. Expect it to take effect within the next couple of hours

[#13]

Just as a small point of interest, my Thompson only gives those occasional spurious up errors when it's started/re-started with the PC switched off. Not at all with the PC switched on. So I guess the errors are no more than some sort of fictitious "non communication" bug?
I wonder if it is the same with yours?