Добрый день

Столкнулся с такой проблемой. Система на stm32f217 работает под FreeRTOS. Использую LWIP и самопальный вэб сервер. Помимо этого идет двунаправленный поток UDP пакетов и отдельно медленный TCP коннект к другому серверу. Если вэб сервер хорошо нагрузить, например с помошью JMeter, то через некоторое случайное время MAC начинает отправлять пакеты с нулевой CRC. Естественно комп их дропает. Все рвется. Потом медленный TCP коннект пытается подключится к компу и шлет повторно SYN пакет с CRC0 в попытке восстановить соединение. Пока помогает только перезагрузка. Дискрипторы в норме. TDES0: 0x30D00000.
Нашел жалобу на это, но без решения... http://lwip.100.n7.nabble.com/CRC-of-each-...F4-td23334.html

В этой жалобе путаница: контрольная сумма заголовка IP или некая CRC (Ethernet frame CRC?) Короче, непонятно.
Если речь идёт о контрольной сумме заголовка, то можно отключить подсчёт в железе, пусть lwip считает.

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

чиссо из опыта - очень смахивает на плохой анализ состояния канала
(это та логика, что отрабатывает по таймеру - очистка, подтверждения и прочая лабуда).
В своё время обнаружил там тупое отсутствие строк 5. Как последствие - долго рвётся соединения при определённых окончании сессии,
кушается память и дескрипторы, разрываются сессии и прочая хрень... такое очучение, что кто то тупо рабочий код "подкорректировал"
(отсутствует обработчик именно с одним состоянием канала). и проявляться будет не всегда.

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

удачи вам

Если смотреть лог, то в пакете 451 уже нет CRC TCP, а в следующем пакете нет и контрольной суммы заголовка. Не суть важно, как их автор назвал.


контрольные суммы и CRC считает аппаратно MAC. Можно конечно это отключить, и считать ручками или встроенным CRC. Но проблема в том, что MAC неожиданно перестает считать.
Состояние канала роли не играет. После закрытия сокета, создания нового и вызова connect - формируется пакет SYN без CRC.

пока помогает flush TX Fifo
осталось решить, когда его дергать
наверное сделаю пока профилактически перед отправкой пакета, если весь TX тракт отдыхает...

Вы, наверное, не в курсе, что такое CRC. Почитайте на досуге. У TCP нет никакого CRC, там некая контрольная сумма.


Вообще-то важно. Поначалу я думал, что мы обсуждаем Ethernet Frame Check Sequence. Ну и зачем вносить эту путаницу на ровном месте?


Похоже на танец с бубном. С другой стороны, на безрыбье и рак рыба...

ТСР это одна из матрешек с обычной 16 битной суммой. Но если дойти до данных что пойдут по сети, там все таки CRC есть.

И хорошо когда ее считает железо. Я так понимаю происходит какой-то конфликт, данные застревают в ТХ, возможно их туда пихают быстрее чем они уходят в драйвере нет контроля. И потомувсе ломается. Сброс буфера - вовзрат в начальное состояние и CRC возвращается, мне кажется что как-то так...

Возможно. Но тогда это проблема MAC контроллера. Он заведует наполнением Tx FIFO из буфера в памяти.