Почему что-то написано в разделе данных запроса эхо-запроса ICMPv4? - PullRequest
Новая
       65

Почему что-то написано в разделе данных запроса эхо-запроса ICMPv4?

1 голос
/ 31 октября 2019

(Мой вопрос отличается от этого одного.)
Я подключен к точке доступа в беспроводной сети и отправил простой запрос пинга на www.google.com . Когда я анализирую пакет в wireshark, я вижу, что в разделе данных ICMP записано 48 байтов. После 8 байтов значений корзины значения последовательно увеличиваются с 0x10 до 0x37.
Есть ли какая-либо конкретная причина, почему ICMPv4 подходит для значений, а не просто с помощью набора нулей?

hexdump раздела данных ICMPv4: 

0030         09 d9 0d 00 00 00 00 00 10 11 12 13 14 15     .Ù............
0040   16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25   .......... !"#$%
0050   26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35   &'()*+,-./012345
0060   36 37                                             67

1 Ответ

2 голосов
/ 01 ноября 2019

После 8 байтов значений корзины

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

Как упоминалось @ ross-jacobs, RFC 792 описывает эхо-запрос ICMP /Пакеты ответов. Для ясности эти два пакета описаны в соответствующей части следующим образом:

Ответное эхо-сообщение или ответное эхо-сообщение 

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-

   ...

   Description

      The data received in the echo message must be returned in the echo
      reply message.

Здесь вы можете видеть, что содержимое Данных не описано ввсе;поэтому реализация может свободно использовать любые данные, которые она пожелает, в том числе и вовсе.

Теперь, поскольку ping - это инструмент сетевого тестирования, одной из вещей, которую он может помочь протестировать, является фрагментация / повторная сборка. Каждая известная мне ping реализация позволяет пользователю указать размер полезной нагрузки, и если вы превысите MTU, вы должны увидеть фрагмент ICMP-пакета / повторно собранный. Если вы изучите полезную нагрузку первого фрагмента, вы можете определить, где должен начинаться второй фрагмент, просто взглянув на последовательность байтов в полезной нагрузке первого фрагмента. Если бы данные были все 0, это было бы невозможно сделать. Точно так же, если ICMP-пакет не был повторно собран должным образом, контрольная сумма, скорее всего, будет неправильной, но вы, скорее всего, сможете точно определить, где произошла ошибка повторной сборки из-за разрыва или другой несогласованности в полезной нагрузке. Это только один пример того, почему полезная нагрузка с последовательностью байтов вместо всех 0 более полезна для пользователя.

...