Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Протоколы Отчет №7

.pdf
Скачиваний:
0
Добавлен:
30.04.2026
Размер:
474.91 Кб
Скачать

МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТЕЛЕКОММУНИКАЦИЙ ИМ. ПРОФ. М. А. БОНЧ-БРУЕВИЧА» (СПбГУТ)

Кафедра программной инженерии и вычислительной техники (ПИиВТ) Факультет информационных технологий и программной инженерии (ИТПИ)

ЛАБОРАТОРНАЯ РАБОТА №7

«Анализ содержимого Ethernet-кадра»

по дисциплине «Протоколы, сервисы и услуги в IP-сетях»

Выполнил:

студент 3-го курса

дневного отделения

группы ИКПИ-32

Яковлев М. А. Кларк А. Е.

Преподаватель:

Горбачева Л. С.

Санкт-Петербург

2026

Постановка задачи

Открыть файл zeros_in_pkt_1214.pcap в Wireshark. Найти в нем

Ethernet-кадр №1214. В конце этого кадра имеется 6 нулевых байт, которые современные версии Wireshark определяют как Padding, относящийся к

Ethernet. Однако так Wireshark эти байты интерпретировал не всегда, да и у других анализаторов трафика мнения по этому поводу расходятся. Известно, что разные протоколы используют Padding (т. е. заполнение незначащей информацией) с различными целями: для выравнивания по определенной границе, для дополнения до минимального размера и т.п. Необходимо выяснить, что это за байты и какому протоколу они принадлежат: TCP, IP или Ethernet.

Ход работы

Рассчитаем контрольную сумму TCP, полагая, что 6 нулевых байт в конце принадлежат данному протоколу. Также рассчитаем контрольную сумму TCP, полагая, что 6 нулевых байт в конце не принадлежат ему. Сравним полученные значения с содержимым поля Checksum (рис. 1).

Рисунок 1 — Ethernet-кадр 1214. Пакет TCP. Контрольная сумма TCP в Wireshark: 0xE194 (0030, смещение 2). Состав кадра указан справа снизу в 16-СС

2

1.Расчет контрольной суммы TCP вручную без учета 6 нулевых байтов

Распишем сложение шестнадцатеричных 16-битных чисел по правилам TCP (с циклическим переносом). Все числа:

1.D946 — IP-адрес источника, байты 1–2

2.81F2 — IP-адрес источника, байты 3–4

3.82E6 — IP-адрес назначения, байты 1–2

4.348B — IP-адрес назначения, байты 3–4

5.0006 — зарезервированный байт (0x00) + протокол (0x06 = TCP)

6.0014 — длина TCP-сегмента (заголовок + данные)

Вычисление: значение 0x0014 в шестнадцатеричной системе = 1×16 + 4 = 20 (десятичных). В псевдозаголовке TCP это поле необходимо для вычисления контрольной суммы.

длина TCP-сегмента = общая длина IP-пакета (из IP-заголовка) − длина IPзаголовка (в байтах). Здесь это: 40 - 20 = 20.

7.0050 — порт источника (0x50 = 80, обычно HTTP)

8.041B — порт назначения (0x41B = 1051)

9.2A6E — последовательный номер, байты 1–2

10.464D — последовательный номер, байты 3–4

11.8470 — номер подтверждения, байты 1–2

12.A6AA — номер подтверждения, байты 3–4

13.5010 — смещение данных (4 бита) + резерв (3 бита) + флаги (9 бит)

14.1B54 — размер окна

15.0000 — обнуленное поле контрольной суммы, чтобы старое значение не участвовало в расчете нового

16.0000 — срочность.

Берём начальную сумму S = 0x0000. Каждое следующее число прибавляется к S, затем перенос (если сумма превышает 0xFFFF) добавляется к младшим 16 битам.

Шаг 1:

S = 0x0000 + 0xD946 = 0xD946 (переноса нет)

Шаг 2:

0xD946 + 0x81F2 = 0x15B38

3

Младшие 16 бит: 0x5B38, перенос 1 → S = 0x5B39

Шаг 3:

0x5B39 + 0x82E6 = 0xDE1F (меньше 0xFFFF, переноса нет)

S = 0xDE1F

Шаг 4:

0xDE1F + 0x348B = 0x112AA

Младшие 16 бит: 0x12AA, перенос 1 → S = 0x12AB

Шаг 5:

0x12AB + 0x0006 = 0x12B1 → S = 0x12B1

Шаг 6:

0x12B1 + 0x0014 = 0x12C5 → S = 0x12C5

Шаг 7:

0x12C5 + 0x0050 = 0x1315 → S = 0x1315

Шаг 8:

0x1315 + 0x041B = 0x1730 → S = 0x1730

Шаг 9:

0x1730 + 0x2A6E = 0x419E → S = 0x419E

Шаг 10:

0x419E + 0x464D = 0x87EB → S = 0x87EB

Шаг 11:

0x87EB + 0x8470 = 0x10C5B

Младшие 16 бит: 0x0C5B, перенос 1 → S = 0x0C5C

Шаг 12:

0x0C5C + 0xA6AA = 0xB306 → S = 0xB306

Шаг 13:

0xB306 + 0x5010 = 0x10316

Младшие 16 бит: 0x0316, перенос 1 → S = 0x0317

Шаг 14:

0x0317 + 0x1B54 = 0x1E6B → S = 0x1E6B

Шаги 15–16:

Прибавление 0x0000 и 0x0000 не меняет сумму.

4

Итоговая сумма: 0x1E6B. После NOT она станет равна Е194. Совпадение с данными из Wireshark.

2. Ручной расчет с учетом 6 нулевых байт

Список чисел:

1.D946

2.81F2

3.82E6

4.348B

5.0006

6.001A (здесь 001A вместо 0014 — длина TCP-сегмента 26 байт)

7.0050

8.041B

9.2A6E

10.464D

11.8470

12.A6AA

13.5010

14.1B54

15.0000

16.0000

17.0000

18.0000

19.0000

Начальная сумма: S = 0x0000

Шаг 1:

S = 0x0000 + 0xD946 = 0xD946 (переноса нет) → S = 0xD946

Шаг 2:

0xD946 + 0x81F2 = 0x15B38

Младшие 16 бит: 0x5B38, перенос 1 → S = 0x5B39

5

Шаг 3:

0x5B39 + 0x82E6 = 0xDE1F

Шаг 4:

0xDE1F + 0x348B = 0x112AA

Младшие 16 бит: 0x12AA, перенос 1 → S = 0x12AB

Шаг 5:

0x12AB + 0x0006 = 0x12B1 → S = 0x12B1

Шаг 6:

0x12B1 + 0x001A = 0x12CB → S = 0x12CB

Шаг 7:

0x12CB + 0x0050 = 0x131B → S = 0x131B

Шаг 8:

0x131B + 0x041B = 0x1736 → S = 0x1736

Шаг 9:

0x1736 + 0x2A6E = 0x41A4 → S = 0x41A4

Шаг 10:

0x41A4 + 0x464D = 0x87F1 → S = 0x87F1

Шаг 11:

0x87F1 + 0x8470 = 0x10C61

Младшие 16 бит: 0x0C61, перенос 1 → S = 0x0C62

Шаг 12:

0x0C62 + 0xA6AA = 0xB30C → S = 0xB30C

Шаг 13:

0xB30C + 0x5010 = 0x1031C

Младшие 16 бит: 0x031C, перенос 1 → S = 0x031D

Шаг 14:

0x031D + 0x1B54 = 0x1E71 → S = 0x1E71

Шаг 15:

0x1E71 + 0x0000 = 0x1E71

Шаг 16:

0x1E71 + 0x0000 = 0x1E71

6

Шаг 17:

0x1E71 + 0x0000 = 0x1E71

Шаг 18:

0x1E71 + 0x0000 = 0x1E71

Шаг 19:

0x1E71 + 0x0000 = 0x1E71

После NOT получаем контрольную сумму E18E. Не совпадает.

Рассчитаем контрольную сумму заголовка IPv4, полагая, что 6 нулевых байт в конце принадлежат данному протоколу. Также рассчитаем контрольную сумму IPv4, полагая, что 6 нулевых байт в конце НЕ принадлежат ему. Сравним полученные значения с содержимым поля Header

Checksum (рис. 2).

Рисунок 2 — IPv4. Header Checksum. Контрольная сумма IPv4 в Wireshark: 0x4B5D (0010,

смещение 8).

1. Без учёта 6 нулевых байт (длина пакета = 0x0028)

Список слов:

1.4500 — Version/IHL/DSCP/ECN

2.0028 — Total Length (40 байт)

3.F0C8 — Identification

4.4000 — Flags + Fragment Offset

5.2C06 — TTL + Protocol

6.0000 — Header Checksum (обнулён)

7.D946 — Source IP (байты 1-2)

8.81F2 — Source IP (байты 3-4)

9.82E6 — Dest IP (байты 1-2)

10.348B — Dest IP (байты 3-4)

Сложение (S = 0x0000):

·Шаг 1: S = 0x0000 + 0x4500 = 0x4500

·Шаг 2: 0x4500 + 0x0028 = 0x4528

·Шаг 3: 0x4528 + 0xF0C8 = 0x135F0

Переполнение: младшие 16 бит = 0x35F0, перенос 1 → S = 0x35F1

·Шаг 4: 0x35F1 + 0x4000 = 0x75F1

·Шаг 5: 0x75F1 + 0x2C06 = 0xA1F7

7

·Шаг 6: 0xA1F7 + 0x0000 = 0xA1F7

·Шаг 7: 0xA1F7 + 0xD946 = 0x17B3D

Младшие 16 бит = 0x7B3D, перенос 1 → S = 0x7B3E

·Шаг 8: 0x7B3E + 0x81F2 = 0xFD30 (нет переполнения)

·Шаг 9: 0xFD30 + 0x82E6 = 0x18016

Младшие 16 бит = 0x8016, перенос 1 → S = 0x8017 · Шаг 10: 0x8017 + 0x348B = 0xB4A2

Промежуточная сумма: 0xB4A2

Контрольная сумма (дополнение до 1): ~0xB4A2 & 0xFFFF = 0x4B5D Совпадает с Wireshark.

2. С учётом 6 нулевых байт (длина пакета = 0x002E)

Список слов:

Тот же, но 0028 заменён на 002E:

1.4500

2.002E ← изменено

3.F0C8

4.4000

5.2C06

6.0000

7.D946

8.81F2

9.82E6

10.348B

Сложение:

·Шаг 1: 0x0000 + 0x4500 = 0x4500

·Шаг 2: 0x4500 + 0x002E = 0x452E

·Шаг 3: 0x452E + 0xF0C8 = 0x135F6

Младшие 16 бит = 0x35F6, перенос 1 → S = 0x35F7

·Шаг 4: 0x35F7 + 0x4000 = 0x75F7

·Шаг 5: 0x75F7 + 0x2C06 = 0xA1FD

·Шаг 6: 0xA1FD + 0x0000 = 0xA1FD

·Шаг 7: 0xA1FD + 0xD946 = 0x17B43

0x7B43 + 1 = 0x7B44

·Шаг 8: 0x7B44 + 0x81F2 = 0xFD36

·Шаг 9: 0xFD36 + 0x82E6 = 0x1801C

0x801C + 1 = 0x801D

·Шаг 10: 0x801D + 0x348B = 0xB4A8

Промежуточная сумма: 0xB4A8

Контрольная сумма: ~0xB4A8 = 0x4B57. Не совпадает с Wireshark.

0000 в шестой позиции — это поле Header Checksum (контрольная сумма заголовка IPv4). При вычислении контрольной суммы это поле должно быть

8

обнулено (установлено в 0), иначе в расчёте участвовало бы старое значение, что неверно.

Теперь включим отображение FCS — четырёхбайтное значение CRC,

используемое для выявления ошибок передачи). В пакете теперь отображается Padding, который относится к Ethernet (рис. 3).

Рисунок 3 — Дополнение относится к Ethernet

Заключение

В результате выполнения лабораторной работы мы выяснили, что нулевые байты принадлежат протоколу Ethernet. Причем нулевые байты — это байты дополнения. Ethernet требует, чтобы все пакеты имели длину не менее 64 байт, причем длина поля данных должна быть не менее 46 байт

(рис. 5). MAC Header и CRC Checksum имеют фиксированную длину, а длина поля данных варьируется от 46 до 1500 байт. Нулевые байты добавляются в конец поля данных, если и только если исходная длина поля данных менее 46

байт. В Wireshark можно увидеть только 60 байт (MAC Header + Data),

оставшиеся 4 байта (CRC Checksum) Wireshark по умолчанию не получает от сетевого драйвера.

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

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

Wireshark; дополнение осуществляется аппаратными средствами Ethernet;

пакеты, посылаемые компьютером, фиксирующем трафик, передаются программе перед передачей аппаратным средствам.

9