☰

«законное» отравление ARP машиной, объединяющей 2 сетевых карты, приводит к сбою

tag-icon • tag-icon networking ip arp
«законное» отравление ARP машиной, объединяющей 2 сетевых карты, приводит к сбою

Происходят странные вещи, поступают угрозы, и нам нужно разобраться с этой проблемой;

Ситуация:

Наше устройство (сетевая камера) транслирует видео по сети на рекордер/сервер (используя Live555 / WIS Streamer). Видео — это пакеты UDP.

На одном конкретном сайте, использующем один конкретный сервер, время от времени (~24 часа) один поток стримера Live555 блокируется во время отправки видео. Другие потоки продолжают работать, и мы все еще имеем подключение к камере по IP - видим веб-страницы с нее, пингуем ее и т. д.

Мы подозреваем,: сервер; у него 2 сетевых порта, и он их объединяет - у него два MAC, но один IP-адрес. При анализе с помощью Wireshark мы видим, что камера передает поток на один порт (назовем его A), затем получаем ARP с другого порта (назовем его B), наше устройство прекращает отправлять пакеты на MAC A, отправляет один пакет по проводу на MAC B, а затем, по-видимому, останавливается.

Дополнительная информация: Похоже, сервер повреждает пакеты ARP из «неправильного» порта, возможно, из-за неправильной настройки или чего-то в этом роде, но эти пакеты все равно считываются и обрабатываются нашим устройством, возможно, из-за неправильной настройки сетевого драйвера или ядра или пропуска контрольных сумм для экономии циклов ЦП.

Итак, эта запутанная ситуация вызывает несколько вопросов:

  1. Где в сетевом коде ядра мне следует проверить контрольную сумму пакета или включить проверку? Наше оборудование фиксировано, поскольку является встроенным устройством, поэтому внесение изменений в драйвер — не самая плохая идея.
  2. Может ли кто-нибудь угадать механизм сбоя, который приводит к блокировке процесса, когда он постоянно send()передает данные на порт, а таблицы ARP под ним смещаются?

Отредактировано для добавления: Теперь мы подозреваем, что ARP на самом деле не повреждены, просто Wireshark неправильно идентифицирует пакет (он думает, что пакет достаточно длинный, чтобы в нем было слово FSC, но теперь мы думаем, что это просто заполнение нулями). Это на самом деле просто оставляет часть 2 этого вопроса: что мы можем сделать, чтобы это изменение в таблице ARP не сбивало процесс передачи?

Отредактируйте, чтобы добавить:Я не хочу, чтобы люди думали, что я игнорирую вопросы о состояниях портов или процессов. Проблема возникает очень редко (в среднем, может быть, раз в 24 часа) и только на одной (удалённой) установке, к которой мы не можем легко получить доступ. Мы изо всех сил пытаемся воспроизвести её в лаборатории, чтобы провести более подробную диагностику, но сторожевой таймер системы сбрасывается примерно через 3 минуты после возникновения проблемы, поэтому к тому времени, как новости доходят до нас, система уже перезагружена и начинает работать нормально.

Измените, чтобы добавить информацию Wireshark: Я не уверен, как лучше всего обобщить здесь захваты Wireshark (очень сложно загрузить ~1 ТБ захваченных пакетов!), но я попробую. Cam:X& Cam:Y— это два потока RTSP-видео, транслируемых двумя идентичными экземплярами Live555 WIS Streamer с разных портов. Серверы «A» и «B» — это MAC-адреса двух сетевых карт на сервере.

Последовательность пакетов выглядит следующим образом:

UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
ARP Packet to Cam from Server 'B' "<my IP> is now on 'B'"
Intel ANS Probe broadcast from Server 'B', Sender ID '1' team ID 'B'
Intel ANS Probe broadcast from Server 'A', Sender ID '2' team ID 'B'
<silence> from Cam:X
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'

В это время или около этого в потоке нет других пакетов. Пакеты Intel ANS не всегда совпадают с ARP от NIC, но я подумал, что включу их для полноты картины.

Проблема, похоже, ОЧЕНЬ чувствительна к времени, мы регулярно видим эти "командные" ARP с сервера, и только раз в году они вызывают у нас проблему - как будто есть определенная точка в коде сетевого стека, которая чувствительна к изменению таблицы ARP. Не всегда падает тот же экземпляр потока, и, что примечательно, другой экземпляр (а также весь остальной сетевой трафик - HTTP и т. д.) продолжает нормально работать.

Похоже, что объединенные сетевые карты «не должны» использовать ARP в середине сеанса, но, конечно, они не будут знать ни о каком сеансе, если весь трафик — UDP.

решение1

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

Связанный контент