Как проверить содержимое возвращаемого пакета в ICMP Ping / Echo?

Question

При проверке ping echo кажется, что утилиты / библиотеки часто проверяют только контрольную сумму пакета и фактически не подтверждают, что отправленная полезная нагрузка соответствует полезной нагрузке, которая была возвращена.Например, анализатор ICMP Wireshark проверяет только неверные контрольные суммы, и это все, что есть у Ruby сеть-ruby чеки тоже.

Я отлаживаю проблему с низкоуровневым сетевым драйвером, и мне нужно подтвердить, что данные не искажаются при получении, поэтому я хочу протестировать свой драйвер, используя низкоуровневый запрос, такой как ICMP - Эхо.Однако моих существующих инструментов Ping недостаточно, потому что я боюсь, что, хотя контрольная сумма может совпадать с данными, содержащимися в эхо-ответе, данные в эхо-ответе не совпадают с данными в эхо-запросе.Таким образом, даже несмотря на то, что они оба имеют действительные контрольные суммы (в коде контрольной суммы нет ошибки), в части приема данных есть ошибка, из-за которой мой драйвер не получает то, что, по мнению хоста, он отправляет.

Как я могу проверить полезную нагрузку echo, чтобы подтвердить, что она совпадает с тем, что я отправил?Если есть автономная утилита "paranoid ping", которую я мог бы использовать, это тоже прекрасно -- Мне просто нужно иметь возможность изменять длину и частоту пинга, поскольку я вижу проблему только тогда, когда сеть переполнена.

Я бы предпочел его в виде библиотеки Ruby / сниппета, но приемлем любой язык или отдельное приложение, если я могу включить его для запуска в Windows.

Спасибо!

Answer 1

@Том:Спасибо за ответ.Ты сказал:

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

Но тогда вы также сказали:

Контрольная сумма ICMP не включает заголовки TCP, только поля типа ICMP, кода, контрольной суммы и данных.

Тип ICMP отличается для эхо-запроса / ответа (один равен 0, другой, я думаю, 8).Таким образом, по определению (и на практике, если вы посмотрите с помощью Wireshark) контрольные суммы ICMP не совпадают между запросом на отправку и ответом echo.

Моя проблема заключалась в том, что если утилиты / библиотеки ping что-либо проверяли (а часто они этого не делали), они проверяли только для того, чтобы убедиться, что контрольная сумма соответствует данным.Похоже, что лишь в редких случаях люди действительно проверяют отправленные данные с помощью echo'd response, чтобы убедиться, что две полезные нагрузки идентичны.Возможно, что и запрос, и ответ могут иметь действительные контрольные суммы, но разная полезная нагрузка, и большинство процедур Ping, которые я видел, не проверяли наличие такого условия (но это своего рода ошибка, с которой я сталкиваюсь на своем устройстве в данный момент).

Спасибо, что посмотрели на мой вопрос и ответили, хотя - это очень ценно.

@Все:

В ответ на мой собственный вопрос я смог использовать надежный .Net-Пинг класс, поскольку он дает мне готовый доступ к полученному буферу ответов (в отличие от большинства других библиотек Ping, которые я нашел).

Answer 2

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

Вы смотрите на контрольную сумму TCP или ICMP?Контрольная сумма ICMP не включает заголовки TCP, только поля типа ICMP, кода, контрольной суммы и данных.Сбой контрольной суммы TCP не обязательно означает, что содержимое ICMP не является неповрежденным, это может просто означать, что заголовки TCP были изменены (возможно, из-за неисправного NAT).