Почему ping получает еще один пакет команд ping?

Question

Я узнаю о реализации ping в C. Проблема в том, что я использовал сырые сокеты для получения пакета. Для всех пакетов мы имеем идентификационное значение в ICMP header.

Я работал под управлением ping в нескольких терминалах.

Например, я использовал три ping google.com в трех терминалах.

Для первого пинг значение идентификации 23456, второе значение идентификации пинг 34564, а третье значение идентификации пинг 98763.

Моя проблема является второй пинг должен получает идентификацию с 34564 пакета, но получает идентификационное значение как 23456.

Для каждого пинга создается новый сырой сокет. Но он получает еще один пакет ping.

Может ли кто-нибудь объяснить мне, почему он получает еще один пакет ping?

UPDATE: -

У меня есть еще одно сомнение. У сомнений есть:

сырые сокеты считывают пакет откуда и как он идентифицирует пакет для этого сырого сокета?

UPDATE 1: -

Вот ссылка для кодов.

ping_common.c

ping.c

ping.h

Answer 1

Что вы видите, дизайн сырого сокета, так как сырые сокеты предназначены для получения всех исходных пакетов. Поэтому, чтобы получать ответ только на некоторые ICMP-пакеты, вам необходимо применить фильтры в сокете. Во-первых вы можете использовать ICMP_FILTER опции сокетов, чтобы ограничить получение определенных типов ICMP:

struct icmp_filter filter; 
filter.data = <bit mask of ICMP types, like ICMP_REPLY>; 
setsockopt(sock, SOL_RAW, ICMP_FILTER, &filter, sizeof filter) 

Во-вторых, вы можете прикрепить гнездо фильтра для обеспечения только получить пакет с данным ICMP ID:

struct sock_fprog filter; 
// set filter to check ID with your own ID 
setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER, &filter, sizeof filter); 

Answer 2

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

• необработанные сокеты считывают пакет откуда и как он идентифицирует пакет для этого сырого сокета?

Сырое гнездо сидеть рядом с другими обработчиками протоколов после слоя IP. Из книги «Знакомство с внутренними сетями Linux» Глава 25.5:

Вот некоторые примеры взаимодействий между протоколами:

протокол IP-

ip_local_deliver_finish процедура, описанная в главе 24, обеспечивает Ingress сообщения ICMP для приема обычной icmp_rcv, зарегистрированной в ICMP, но он также доставляет их в исходные IP-сокеты , которые зарегистрированы на ICMP-протоколе (raw_v4_input).