ICMP-эхо-запросы не отправляются при получении пакетов «Destination Unreachable»

Question

Я работаю над приложением для управления сетью, которое управляет хостами с использованием ICMP через raw-разъемы BSD (sendto).

Мой вопрос не в том, как это сделать, на самом деле он работает очень хорошо. Кажется, что я только сталкиваюсь с проблемой, когда целевой хост отправляет Destination unreachable сообщений на сервер управления, пока я пытаюсь отправить ICMP-эхо-запрос этому хосту.

Когда хост добавлен в приложение управления, он будет протестирован с использованием указанного ICMP-пинга, и в то же время начнется «обнаружение», тестирование различных портов на хосте, таких как SNMP (161) и т. Д. используя соответствующие протоколы, необходимые для этого.

Теперь я знаю, что не имеет смысла выполнять это «обнаружение» на хосте, где я не знаю, существует ли он или отвечает (то есть он отправил ответ ICMP-эха), но для этого вопроса это имеет решающее значение. Предположим также, что хосты, о которых идет речь, действительно достижимы и реагируют на сигналы ICMP, например. через командную строку ping.

«Открытие» в конечном итоге вызывает некоторые ICMP «Destination unreachable: Port unreachable» пакеты, которые будут отправлены обратно на сервер управления, например. когда на целевом хосте нет агента SNMP, а порт 161, по сути, недоступен.

Это совершенно нормально, но по некоторым причинам это мешает ICMP-сокету отправлять ICMP-запрос эха на этот хост, который требуется для ICMP-пинга. Поскольку этот запрос никогда не отправляется, мое приложение не получает ответа, и хост будет считаться «недоступным» через некоторое время (время ожидания).

Я проанализировал сетевой трафик с помощью Wireshark, таким образом, я могу сказать, что на целевой хост не передается эхо-запрос ICMP. Приложение, в котором я работаю, также имеет функцию «опроса статуса», которая может использоваться для «ручного» выполнения другого ICMP-запроса на этом хосте. Если это используется после добавления хоста (то есть не более Недоступный пункт назначения пакетов поступает), эхо-запрос отправляется без проблем.

Я озадачен тем, что запрос ICMP-эха не отправляется в ситуации, описанной выше. У меня есть еще один ICMP-сокет, который принимает все входящие пакеты ICMP (чтобы реагировать на ответы), но он не должен влиять на отправляющий сокет, не так ли? В моем коде нет реакции, определенной для сообщений Destination unreachable, их просто игнорируют, поэтому я очень уверен, что это не мой собственный код, который отключает отправку запроса.

Фактически, функция sendto, отвечающая за отправку запроса, выполнена (удостоверившись в этом путем отладки) и даже возвращает успех (количество отправленных байт), но пакет фактически не отправляется. Я могу воспроизвести это как на Windows, так и на Linux, поэтому я не считаю, что это проблема операционной системы.

Отключение «открытие», что вызывает эти Адресат недостижим сообщения, которые будут отправлены обратно делает все отлично работает снова, так что я довольно уверен, что это те сообщения, которые мешают эхо-запрос ICMP был отправлен. На большой вопрос, на который я не могу найти ответ, есть: Почему?

Я могу предоставить дополнительную информацию, если это необходимо, однако, я боюсь, что мне не разрешено размещать здесь какой-либо код, потому что это коммерческий продукт.Код не является чем-то особенным, хотя, просто отправляя и получая пакеты ICMP (IPv4) с TOS=0 и TTL=64 с использованием сырых ICMP-сокетов.

Answer 1

Dest unreachable генерируется маршрутизатором, или если вы пингоруете в локальной сети, он будет генерироваться локальным хостом.

Я думаю, ваше наблюдение связано с тем, что вы пинговали в локальной сети. Тот факт, что ICMP-3 сгенерирован, означает, что поиск ARP не удался, без поиска ARP вы фактически не можете отправить пакет, потому что вы не знаете целевой MAC-адрес. Это все объясняло.

Так или иначе, вы должны просто ждать фиксированного времени, как секунда, и объявить, что хост не существует, неважно, отправляется ли пакет.