Что останавливает наши UDP-пакеты (как он знает, что маршрут не работает)?

У нас есть сервер (камера), отправляющий видеопакеты RTSP через UDP. На клиентском сайте он перемещается по нескольким прыжкам, один из которых может быть ненадежным соединением WiFi, которое выдает нечетный пакет или пять. Обычно это происходит незамеченным, но иногда он убивает поток в течение нескольких секунд и вызывает неудовольствие клиентов (я знаю, их сеть cr * p – это как-то наша проблема …)

При тестировании с использованием tc для моделирования неудобного соединения мы обнаружили странную ситуацию: если мы разорвем соединение в обратном направлении ( пакеты отбрасываются молча ), через несколько секунд поток пакетов UDP с нашей камеры прекратится, хотя клиент RTSP ( Live555 Wis-Streamer) по-прежнему считает, что это весело Squirting UDP пакеты вверх по трубе.

Это странно, так как очевидно, что UDP-пакеты не ACK'd, а физическая связь никогда не падает, поэтому наша система не знает, что пакеты падают в бит-ведро дальше по цепочке, и стример не знает, что никто не слушает его (тайм-аут сеанса стримера не истекает до конца).

EDIT: Мы видим, что ARPing (Who has < client >) в момент остановки пакетов UDP, но до тех пор, пока он не скажет стеку, что соединение упало.

Поэтому у меня есть два вопроса:

  1. Есть ли какой-то другой механизм, с помощью которого сетевой стек может сказать, что соединение имеет проблемы?
  2. Является ли сетевой стек молчащими пакетами при определенных обстоятельствах?

Чтобы продемонстрировать нашу установку тестирования:

Нормальное состояние, подключение в обоих направлениях:

 Our server <==> Switch <==> TC <==> Switch <==> PC | | Wireshark <-- TAP | | Wireshark <----------------------- TAP 

Состояние сбоя, сброс пакетов TC, возвращающихся на наш сервер:

 Our server --> Switch --> TC <==> Switch <==> PC | | Wireshark <-- TAP | | Wireshark <----------------------- TAP 

2 Solutions collect form web for “Что останавливает наши UDP-пакеты (как он знает, что маршрут не работает)?”

Как только вы разорвете соединение, вы должны начать получать недостижимые пакеты ICMP, чтобы уведомить вас о том, что соединение нарушено. Это обычное поведение IP.

Существуют инструменты, которые будут отслеживать и отображать ICMP-пакеты. Другие инструменты могут использоваться для сброса или захвата всего трафика, соответствующего критериям выбора.

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

Ну, похоже, что таблица ARP стала устаревшей (даже если мы потоки UDP как сумасшедшие, что не пинает тайм-ауты ARP, а трафик TCP намного более разрежен при нормальной работе). Увеличение тайм-аутов прекратило появление проблемы для «разрывов» менее ~ 2 минут (в этот момент время сеанса клиента RTSP истекает):

 ARP gc_staletime extended from 60sec to 360sec ARP base_unreachable time extended from 30sec to 240sec 

К сожалению, это заняло довольно много слов, поскольку мы находимся на Busybox без команды arp , но теперь она кажется надежной для ситуации, которую мы пытаемся обработать.

Я все еще хочу понять, как работает сетевой стек – в тот момент, когда таблица ARP / запись устарела, она перестает отправлять пакеты, но, похоже, не вызывает ошибок в цепочке в коде, который пытается отправить пакеты.

  • RHEL ip n Подключенное устройство имеет устаревшее соединение?
  • Как я могу поделиться своим интернет-соединением (беспроводным) с компьютером только через Ethernet?
  • Профиль AppArmor: запрет доступа в интернет
  • «Легальное» отравление ARP машинным агрегатом 2 сетевых адаптера нарушает нас
  • механизм IP-алиаса
  • установить ip default исходящий в centos
  • Как Linux запрещает приложениям отправлять больше пакетов, чем может обрабатывать ссылка, не отбрасывая пакеты?
  • Не удается выполнить трансляцию
  • Изменение IP-адреса удаленного хоста без потери контроля (Linux)
  • Имя хоста разрешает неправильный IP-адрес
  • скрипты bash не работают при попытке использовать список
  • Пакеты OAM теряются в стеке IP ядра linux
  • Linux и Unix - лучшая ОС в мире.