Ещё раз внимательно читаем по слогам: в TCP-кадрах нет CRC32-контроля.
Вот расчёт контрольной суммы для TCP-кадра из рабочего TCP-стека:

Покажите мне - где здесь CRC32????

Вам шашечки или ехать?
От противного =>
Вы утверждаете, что контрольая сумма даёт сбои при конкретной реализации и посему TCP не надёжен в плане сетевой передачи?

Если нет - тогда не понятен изначальный посыл. Если да, то собственно это немного противоречит мировой практики, несколько тонн кода и
фиг знает сколько часов работы...

На самом деле я что-то тоже в какой-то момент начал думать что в ТСР CRC32, но для себя эту проблему решил прочитав еще раз формат пакета, там обычная 16 битная сумма.

Такая контрольная сумма весьма не дурна, но не гениальна. Она не замечает перестановку слов, и двойную ошибку одного бита. Учитывая сетевой протокол, избыточное кодирование и прочее она годиться для ТСР (вот теперь сижу вспоминаю а есть ли там избыточное кодирование), и дает единицы ошибок в год, но CRC32 в разы надежнее...

Принимать из интернета битые файлы - это нормальная практика, не скажу чтобы так каждый день, но при передачи файлов по сети такое несколько раз случалось, так что проблема не мифическая.

Единственное я бы не стал встраивать контрольную сумму в FTP, все таки это вне протокола, то есть я бы принял файл, а потом проверил и выставил бы какой-то признак файлу, так было бы идеологически правильнее, чем передавать сигнал прием завершен или нет в зависимости от целостности, но это на усмотрение автора...

Хорошо, в TCP простая сумма. Но этот TCP идет поверх Ethernet, в котором как раз таки CRC-32.
Википедия:

Вот оно откуда воспоминание о CRC32, ведь помнил что был какой-то гемор в железной его реализации%)))

Неужели тогда не хватает CRC32, ведь реально по сети есть шансы скачать битый файл...

Пропускают ошибки любые методы контроля. Вопрос в вероятности. А по этому критерию CRC32 несравнимо лучше обычной суммы.
И если поддаться паранойе, то можно не ограничиваться 32 разрядами. Есть полиномы и на большие разрядности.


А где ТС пишет, что клиент и сервер находятся в одной Ethernet-сети?
Он вроде про Интернет пишет. А значит - на пути следования пакета могут быть различные физические+канальные среды передачи.
Плюс - переход пакета из одного сегмента сети в другой, через кучу маршрутизаторов.
Не здесь-ли и возникают сбои, приводящие к ошибкам в принятых по FTP файлах?

А ещё - как я понимаю для Ethernet обязательно только формирование кадров с CRC, но не обязателен контроль этой CRC на приёмной стороне.


Я бы сказал - не в разы, а на порядки. Учитывая кол-во разрядов в контрольной сумме TCP и в CRC32. Уж не говоря о том что даже CRC16 будет надёжнее обычной суммы.
Кодирование - это функция вроде канального или физического уровня протокола (в частности - Ethernet-уровня или какой там канальный/физический уровень в данном сегменте). А TCP - это более высокий уровень OSI.