Я работаю над приложением, которое генерирует сетевой трафик. В приложении есть eth1 в беспорядочном режиме. Таким образом, он напрямую обрабатывает весь входящий и исходящий трафик.
Одна из реализуемых мною функций - это фрагментация и дефрагментация IP. Входящие фрагменты необходимо повторно собрать, а исходящие пакеты необходимо фрагментировать, если их размер превышает MTU в 1500 байтов.
Один простой способ протестировать мое приложение - отправить ping команду на IP-адрес eth1:
ping -c1 -s 20000 10.3.2.1
Это нормально работает.
Однако, как только размер пакета превышает ~ 53000 байт, происходит сбой. Согласно Wireshark, я получаю фрагменты до смещения фрагмента ~ 51000, а затем ничего, после чего следует тайм-аут повторной сборки.
Максимальный размер IP-пакета составляет 65535 байт. В ping позволяет указать размер до 65507. Это действительно работает, если я пингую eth0 (Под управлением ОС).
При осмотре приложения изнутри с помощью GDB все идет хорошо. Пошаговое выполнение кода показывает, что фрагменты входят в мое приложение, IP-пакет успешно повторно собирается, а затем снова фрагментируется, а фрагменты отправляются обратно отправителю. Даже для последнего фрагмента возвращаемое значение send(...) (API сокета) равен размеру фрагмента, что указывает на успех.
Кто-нибудь знает, что может пойти не так?
Операционная система - Linux (на основе RTLinux).
Если пакеты правильно фрагментированы, затем собираются заново на стороне клиента, но обратное не работает,
A -----> B
|
A <--x-- B
Я бы посоветовал сначала попробовать поменять местами роли (поскольку проблема уже на обратном пути) и проверить, могут ли фрагментированные пакеты / повторная сборка на этот раз выполняться A
A <----- B
|
?
В противном случае существует проблема в управлении пакетами от B к A, это может быть ограничение брандмауэра или любой маршрутизатор или коммутатор, которые могут быть между ними.
The maximum TCP segment you can have is 65,495 bytes.
Если вас интересуют заголовки ... это может быть граница, которую вы ищете:>
Кроме того, у вас есть постоянное окно для TCP или оно адаптируется само? Возможно, используется меньшее окно, и вы не можете отправить больше данных
Проблема заключалась в потере пакетов. IP-ответ был отправлен на коммутатор по гигабитной линии. Этот коммутатор, в свою очередь, пересылал сообщения по линии 100 Мбит. Это означает, что пакеты приходили с большей скоростью, чем оставалась, в результате чего использование памяти внутри коммутатора быстро возрастало. Как только вся память была использована, у коммутатора не было другого выбора, кроме как начать отбрасывать пакеты.