stm32f217 MAC перестает считать CRC для исходящих пакетов Опции

[alexp74]

Добрый день

Столкнулся с такой проблемой. Система на 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

[scifi]

Нашел жалобу на это, но без решения...

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

[kolobok0]

..Пока помогает только перезагрузка...

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

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

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

удачи вам

[alexp74]

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

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

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

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

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

удачи вам

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

[alexp74]

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

[scifi]

Если смотреть лог, то в пакете 451 уже нет CRC TCP

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

Не суть важно, как их автор назвал.

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

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

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

[Golikov A.]

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

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

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

[alexp74]

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

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