BT Network data corruption - how can it happen?

I just registered with the forums with a technical question.

I'm one of the people who are struggling with fibre broadband issues in East Lothian at the moment. I can't really come to any other conclusion than think that the BT network is corrupting packets, I told BT this last week.

See the BT forum for more info...

https://community.bt.com/t5/BT-Infinity-Speed-Connec...

I came up with a test to download the Thinkbroadband 10MB test file and compare two downloads. Using the linux cmp command I see this pattern of errors...

kaze:TB% cmp -l 10* A
4415113 77 73
4415129 32 36
4941117 175 171
4941133 362 366
5835373 45 41
5835389 202 206
6299649 314 310
6299713 120 124
7533817 205 201
7533833 100 104
7739457 122 126
7739473 35 31
8175697 126 122
8175713 343 347
8489709 123 127
8489725 24 20

Does anyone understand core network technology to work out what might be wrong?
Other people, one on Sky have confirmed this pattern so this seems to be independent of client device, ISP and modem/router make.

Edited by deleted (Mon 14-Sep-15 20:00:09)

Perhaps some clues here for anyone who understands 21CN architecture and terminology

https://status.zen.co.uk/broadband/fault-outage-deta...

I suppose if the engineers can't work it out quickly then this will not be obvious to anyone here.

Must be either an issue at a TCP connection boundary or errors not caught by the checksums.

Edited by deleted (Tue 15-Sep-15 00:48:58)

This was caused by a faulty switch.

As per my posting on the BT forum I think this is just a failed checksum as suggested in the comments on the main ThinkBroadband page.

Reproducing my post here...

I think I get it, now that the exchange fault is fixed (others alluded to this earlier).

The TCP checksums are not very sophisticated:

"The Limitations of the TCP and IP checksums

The IP checksum is a 16 bit 1's complement sum of all the 16 bit words in the IP header. Note that this does not cover the TCP header or any of the TCP data. The TCP checksum is a 16 bit 1's complement sum of all the 16 bit words in the TCP header plus the IP source and destination address values, the protocol value (6) and the length of the TCP segment (header + text). For purposes of the calculation the checksum field has a value of 0.

The checksum calculation will NOT detect

Reordering of 2 byte words, i.e. 01 02 03 04 changes to 03 04 01 02
Inserting zero-valued bytes i.e. 01 02 03 04 changes to 01 02 00 00 03 04
Deleting zero-valued bytes i.e. 01 02 00 00 03 04 changes to 01 02 03 04
Replacing a string of sixteen 0's with 1's or 1' with 0's
Multiple errors which sum to zero, i.e. 01 02 03 04 changes to 01 03 03 03"

(from http://noahdavids.org/self_published/CRC_and_checksu... )

In our case what was getting through was a +4/-4 change (or the other way round) within the window of the sum.

No doubt someone will be taking a close look at that bit of hardware.