Проблема с фрагментированными IP-пакетами

[Вадим С]

Тестирую embox на STM32F4.
Если embox получит фрагментированный IP-пакет, то возникает ошибка, устройство отправляется в перезагрузку.
Проверить можно отправив на устройство фрагментированный ICMP-пакет, например из ubuntu так:
sudo hping3 -a 192.168.100.20 192.168.100.100 -I eth0 -f

[Anton Bondarev]

Спасибо.
А какая именно плата и темплейт?

20 марта 2017 г., 23:01 пользователь Вадим С <vsar...@yandex.ru> написал:

--
You received this message because you are subscribed to the Google Groups "embox-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embox-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Kalmuk]

Вадим, добрый день.

sudo hping3 -a 192.168.100.20 192.168.100.100 -I eth0 -f

Кажется эта команда нефрагментированный TCP пакет посылает, а не ICMP. Для ICMP нужен ключ "-1". А чтобы действительно на много фрагментов еще разбить, нужен ключ "-d" со значением большим MTU. В итоге как-то так: 

sudo hping3 -1 -d 1024 -a 192.168.0.12 192.168.100.100 -I wlan0 -f

Присоединяюсь к вопросу Антона, и еще - Вы взяли последнюю версию из мастера?

С уважением,

Александр Калмук

21 марта 2017 г., 12:05 пользователь Anton Bondarev <anton.bon...@gmail.com> написал:

[ac4p...@gmail.com]

Здравствуйте, Александр и Антон!

Да, Вы правы. Плата STM32F4DISCOVERY. После сегодняшних изысканий и экспериментов хотел бы скорректировать проблему:
Проблема с ASSERT при получении любого фрагментированного пакета была связана с тем, что я когда-то установил так:
@Runlevel(2) include embox.net.ipv4(max_uncomplete_cnt=0) и при приёме фрагментированного пакета получал в консоль:
ASSERTION FAILED on CPU 0
at src/net/l3/ipv4/ip_fragment.c:240
in function ip_defrag

Но сегодня я "одумался" и установил max_uncomplete_cnt=16 (как по умолчанию), контроллер перестал перезагружаться, ошибок в консоли нет, но при получении первого же фрагментированного пакета устройство перестаёт взаимодействовать по сети, на пинги не отвечает, хотя другие потоки в контроллере выполняют свои задачи (светодиоды мигают, есть реакция на нажатия кнопки). Выводит контроллер из себя фрагментированный пакет любого типа. В коде есть такой интересный комментарий:
* For some reason we don't like situation when someone used forced fragmentation */
Приведённая команда посылает фрагментированный PING, если устройство отвечает, то команды выведет время ответа, можете попробовать отправить её большому компьютеру, wireshark это тоже подтверждает.

вторник, 21 марта 2017 г., 16:57:08 UTC+3 пользователь Александр Калмук написал:

Вадим, добрый день.

sudo hping3 -a 192.168.100.20 192.168.100.100 -I eth0 -f

Кажется эта команда нефрагментированный TCP пакет посылает, а не ICMP. Для ICMP нужен ключ "-1". А чтобы действительно на много фрагментов еще разбить, нужен ключ "-d" со значением большим MTU. В итоге как-то так: 

sudo hping3 -1 -d 1024 -a 192.168.0.12 192.168.100.100 -I wlan0 -f

Присоединяюсь к вопросу Антона, и еще - Вы взяли последнюю версию из мастера?

С уважением,

Александр Калмук

21 марта 2017 г., 12:05 пользователь Anton Bondarev <anton.bon...@gmail.com> написал:

Спасибо.
А какая именно плата и темплейт?

20 марта 2017 г., 23:01 пользователь Вадим С <vsar...@yandex.ru> написал:

Тестирую embox на STM32F4.
Если embox получит фрагментированный IP-пакет, то возникает ошибка, устройство отправляется в перезагрузку.
Проверить можно отправив на устройство фрагментированный ICMP-пакет, например из ubuntu так:
sudo hping3 -a 192.168.100.20 192.168.100.100 -I eth0 -f

--
You received this message because you are subscribed to the Google Groups "embox-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to embox-devel...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "embox-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to embox-devel...@googlegroups.com.

[ac4p...@gmail.com]

Извините, упустил некоторые ваши вопросы. Версия не самая последняя, но я анализировал вчера вечером изменения связанные с сетью, они больше косметические и похоже не связаны с IP-фрагментацией. Ради интереса я отключил поддержку IP-фрагментации флагом - устройство стабильно работает, при получении фрагментированного пакета просто игнорирует его. Хотелось бы иметь возможность получать и фрагментированные пакеты.

вторник, 21 марта 2017 г., 18:03:12 UTC+3 пользователь ac4p...@gmail.com написал:

[Вадим С]

Пришла замечательная мысль - попробовать зашить в контроллер какой-нибудь "образцовый" темплейт, например, с modbus. Мой был сделан на его основе, но менял я в нём многое пробуя различные настройки.

вторник, 21 марта 2017 г., 19:17:34 UTC+4 пользователь ac4p...@gmail.com написал:

[Вадим С]

Собрал проект stm32f4_cnc конфиг не менял.
Поведение такое же - после выполнения пинга фрагментированным пакетом сеть не работает.

вторник, 21 марта 2017 г., 20:59:15 UTC+4 пользователь Вадим С написал:

[anton.bon...@gmail.com]

Странно.

Мы сейчас приводим в порядок arm/stm32f4cube в качестве базового. Есть проблемы с фрагментацией и выделением памяти под пакеты

21 марта 2017 г., в 21:47, Вадим С <vsar...@yandex.ru> написал(а):

[ac4p...@gmail.com]

Антон, правильно я понял, что вам удалось обнаружить проблему c фрагментацией?
Если так, то она затрагивает все платформы?

вторник, 21 марта 2017 г., 22:12:37 UTC+3 пользователь Anton Bondarev написал:

[Alex Kalmuk]

Вадим,

Да, на stm32f4-discovery с фрагментацией плохо. Фрагментация работает на x86/qemu и arm/qemu, так что похоже проблема в именно в stm.

Сначала подумали, что из-за количества пакетов в конфиге, но похоже бы нет.

Сегодня будем разбираться.

22 марта 2017 г., 10:07 пользователь <ac4p...@gmail.com> написал:

To unsubscribe from this group and stop receiving emails from it, send an email to embox-devel+unsubscribe@googlegroups.com.

[Alex Kalmuk]

Кажется получилось понять проблему. 

Стмка не успевает разгребать очередь входящих пакетов в драйвере. Там очередь на 5 пакетов (физически, похоже). То есть если фрагментов много, и они быстро отсылаются, то мы не успеваем разгребать эту очередь и часть просто теряется.

Как решать эту проблему пока неочевидно (зависит от задачи). Соответственно вопрос. Дейтсвительно ли нужна фрагментация на стмке? Если да, то что-нибудь придумать можно.. Например,

Собрать ембокс с оптимизацией. Либо как-то оптимизировать сам драйвер. И т.д. Можем подумать как Вам помочь.

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

22 марта 2017 г., 12:22 пользователь Alex Kalmuk <alexk...@gmail.com> написал:

[Вадим С]

Александр, не понятно почему сетевой интерфейс перестаёт работать после получения хотя бы одного фрагментированного пакета? Сеть не оживает после. Хотелось бы поддержки IP-фрагментации, так как это базовая вещь. Судя по моим тестам от количества и скорости пакетов это не зависит. Я посылал с помощью той же утилиты не фрагментированные пакеты с опцией --faster (по моему 100 пакетов в секунду), контроллер STN32F4 теряет пакеты, но после снижения нагрузки вновь начинает отвечать на пинги.

Так как в embox использовался код от стека lwip, то вероятно стоит посмотреть как это устроено у него, а именно документ AN3966:
http://www.st.com/content/ccc/resource/technical/document/application_note/fd/5d/64/cf/7c/38/4c/30/DM00036052.pdf/files/DM00036052.pdf/jcr:content/translations/en.DM00036052.pdf
на странице 17 (DMA descriptor handling), для приёма пакетов используются DMA-дескрипторы указывающие на буферы, их количество определяется параметром ETH_RXBUFNB. Судя по результату поиска в ветке master он = 4. В приводимом документе написано, что один Ethernet-пакет может занимать более одного DMA-дескриптора, а также что один DMA-дескриптор может использоваться только одним Ethernet-пакетом.
Поэтому я думаю, что количество выделяемых DMA-дескрипторов слишком мало. Но и это не должно приводить к проблемам, так как буферы образуют кольцо. Проблема может быть в том, что накапливаются фрагменты, которые не могут быть склеяны, то есть дефрагментированы. Но почему? Буферов мало? Наверное не дефрагментированные пакеты должны удаляться по истечении времени жизни пакета (TTL), но и это кажется большим для малой системы и удалять их возможно следует через уже через секунду.
Размер каждого буфера равен константе ETH_RX_BUF_SIZE, которая равна ETH_MAX_PACKET_SIZE. А вот чему последняя равна я не нашёл, но должен быть равен 1524 (не больше).


среда, 22 марта 2017 г., 21:19:12 UTC+4 пользователь Александр Калмук написал:

[Вадим С]

А вот как должен выглядеть алгоритм обработки фрагментов:
При приходе первого фрагмента пакета узел назначения запускает таймер, который определяет максимально допустимое время ожидания прихода остальных фрагментов этого пакета. Таймер устанавливается на максимальное из двух значений: первоначальное установочное время ожидания и время жизни, указанное в принятом фрагменте. Таким образом, первоначальная установка таймера является нижней границей для времени ожидания при c6opке. Если таймер истекает раньше прибытия последнего фрагмента, то все ресурсы сборки, связанные с данным пакетом, освобождаются, все полученные к этому моменту фрагменты пакета отбрасываются, а в узел, пославший исходный пакет, направляется сообщение об ошибке с помощью протокола ICMP.

четверг, 23 марта 2017 г., 0:54:13 UTC+4 пользователь Вадим С написал:

[Alex Kalmuk]

Нет, дело именно в прерываниях. До фрагментации не доходит

23 марта 2017 г., 0:16 пользователь Вадим С <vsar...@yandex.ru> написал:

To unsubscribe from this group and stop receiving emails from it, send an email to embox-devel+unsubscribe@googlegroups.com.

[Alex Kalmuk]

Про удаление пакетов -- согласен. Как раз это сегодня и попробовали

23 марта 2017 г., 1:07 пользователь Alex Kalmuk <alexk...@gmail.com> написал:

[Alex Kalmuk]

Про таймер -- этот код был раньше в общей в части. Можете глянуть файл ip_fragment.c, там есть таймер по ttl. Но в какой-то момент это убрали (мб ломалось qt на vnc). Там даже про icmp пакет есть закоменченная строчка ip_fragment.c:80 :) Действительно, этот момент важен. 

Хорошо, спасибо, мы завтра потестируем еще и с --faster, и подумаем что можно сделать.

[Вадим С]

Александр, хотел бы ещё задать "глупые" вопросы, которые могут навести на полезные мысли:
 - похоже, что для приёма и передачи используется общий обработчик прерываний - stm32eth_interrupt, но в нём нет анализа от чего именно прерывание поступило и выполняются всё безусловно, не знаю полезно ли это?
 - флаги прерываний сбрасываются все ( ETH_DMA_IT_R и ETH_DMA_IT_T) независимо от того сработало оно от передатчика или приёмника, это правильно?
 - проблема может быть с приоритетом прерываний, слишком высокий или низкий?

четверг, 23 марта 2017 г., 2:15:29 UTC+4 пользователь Александр Калмук написал:

[Anton Bondarev]

Вадим, добрый день.

У нас не lwIP, а собственная реализация стека, но это не так важно:)

Мы можем попробовать решить задачу на STM32F4, ведь мы явно не успеваем разгребать пакеты!
Но мне кажется, что основная проблема в том, что у нас в текущей реализации могут залипнуть пакеты, ведь кусок может потеряться при передаче по сети не только на STM32. Причем тот алгоритм который Вы предложили у нас был реализован, но почему то выключен с помощью #if 0. Для того чтобы корректно реализовать и ничего не сломать в остальной системе, нам потребуется пара недель. Если Вам  требуется данная функциональность срочно, опишите пожалуйста подробнее, тогда мы попробуем закостылить для конкретной ситуации.

Спасибо за багрепорти советы, мы проверим эти предположения.

С уважением, Антон Бондарев

23 марта 2017 г., 7:58 пользователь Вадим С <vsar...@yandex.ru> написал:

To unsubscribe from this group and stop receiving emails from it, send an email to embox-devel+unsubscribe@googlegroups.com.

[ac4p...@gmail.com]

Здравствуйте, Антон!

Сначала хотел бы скорректировать описание действия команды hping3 - Александр был прав, изначально приведённая команда на самом деле отправляет два пакета - первый пакет - это фрагментированный TCP, а второй нефрагментированный ICMP. На такую комбинацию пакетов отвечают только компьютеры семейства linux и команда hping3 радостно показывает нам время ответа от сервера, остальные компьютеры молчат.

Что бы отправить фрагментированный ICMP нужно сделать так:
hping3 -a 192.168.100.20 192.168.100.100 -I eth0 -f -1 -d 1000 -m 1000
На эту команду STM32 не отвечает, но и сеть не отваливается, устройство продолжает нормально работать.
Вывод - сеть у STM32 отваливается при приёме фрагментированного пакета не ICMP типа.
Мне кажется, что проблема не в потере пакетов, а в их обработке.
Буду рад если вы сможете корректно обрабатывать фрагментированные пакеты на STM32 через две недели.
Спасибо.
Да, обширный комментарий посреди кода про lwIP - это заслуга программистов st :)

четверг, 23 марта 2017 г., 13:32:15 UTC+3 пользователь Anton Bondarev написал:

[Anton Bondarev]

Вадим, добрый день.

Вроде бы пофиксили предложенным Вами методом. Пока не смерджили, если не трудно проверьте функциональность в PR (https://github.com/embox/embox/pull/1069)

С уважением, Антон Бондарев

23 марта 2017 г., 15:51 пользователь <ac4p...@gmail.com> написал:

To unsubscribe from this group and stop receiving emails from it, send an email to embox-devel+unsubscribe@googlegroups.com.

[Alex Kalmuk]

Вадим, добрый день,

Исправления по IP фрагментации теперь в мастере. 

Мы поверили на темплейте arm/stm32f4cube. Теперь если посылаем сначала большой пинг на 16 кб, то сеть повисает, но через пару секунд пакеты удаляются, и сеть снова работает. То есть с удалением фрагментов должно стать лучше.

Попробуйте, пожалуйста, у себя, как будет время.

С уважением,

Александр Калмук

9 апреля 2017 г., 20:03 пользователь Anton Bondarev <anton.bon...@gmail.com> написал:

[Вадим С]

Здравствуйте, Александр!
Проверил - работает, но если таких пакетов придёт несколько с малым интервалом, то контроллер уходит в перезагрузку. Вы можете повторить это используя hping3 с опцией --fast.

вторник, 11 апреля 2017 г., 18:07:08 UTC+4 пользователь Александр Калмук написал: