Mmmm.. The WD15 contains a Realtek r8153 USB-ethernet chip. Bah!

Performance of those chips is fine, nice and quick. The problem is, as I determined a couple of years ago, under heavy load they contribute to system data corruption.

And sure enough.. google shows me lots of reports of issues with that chip in the TB16 docks. There is a workaround in linux-4.20 to disable "rx aggregation" on the chip in an attempt to work around the issue. The Realtek people are placing the blame on the XHCI USB3 controller used by the dock.

But funny.. I had a completely different USB host controller when I saw the problem, and lots of other reports have surfaced and been ignored over the years with the r815x controllers used on a variety of hardware.

The issues all began when the Linux driver was modified (back in kernel 3.16) to trust hardware rx checksums from the chip, rather than always doing a software checksum.

Well.. despite reports to the contrary, I have already seen one of the symptoms of the issue now in my WD15 dock, and this happens despite the driver mis-detecting it as a TB16 and thus having enabled the workaround already.

So.. I'm hacking my kernel driver to force software checksums in the r8152.c driver, just because once in a billion packet data corruption isn't fun.

Sure, you can do at runtime with an ethtool command, but by then it might already be too late.

Cheers