Wireshark интерпретирует пакеты, захваченные с помощью pktmon, как Ethernet-фреймы, а не как TCP/IP-пакеты.

Вопрос или проблема

Предыстория

  • Я захватываю пакеты HTTP request/response с помощью команды pktmon на компьютере A, переношу результат на другой компьютер B и открываю его с помощью Wireshark.
  • Wireshark не может быть использован для захвата пакетов. Я должен захватить пакеты в приложении в тестовой среде. Установка дополнительного программного обеспечения в эту среду только для целей тестирования запрещена.
  • В качестве теста я захватил пакеты с помощью curl.exe и конвертировал их в файл .pcapng с помощью pktmon etl2pcap следующим образом:

> pktmon start --capture --comp 17 --pkt-size 0 --trace -p Microsoft-Windows-TCPIP --file-name C:\tmp\ETW\pktmon_curl_http_capture.etl

Параметры Логгера:
    Имя логгера:      PktMon
    Режим логгирования: Кольцевой
    Файл лога:        C:\tmp\ETW\pktmon_curl_http_capture.etl
    Максимальный размер файла: 512 MB
    Используемая память:  384 MB

Собранные данные:
    Счетчики пакетов, захват пакетов, события

Тип захвата:
    Все пакеты

Мониторинг компонентов:
    Id Driver       Name
    -- ------       ----
    17 Netwtw08.sys Intel(R) Wireless-AC 9560 160MHz

Фильтры пакетов:
    Нет
PS C:\tmp\ETW> curl.exe "http://httpbin.org/base64/VEVTVCBGUk9NIENVUkw%3D"
ТЕСТ ИЗ CURL
PS C:\tmp\ETW> pktmon stop
Сбрасывание логов...
Объединение метаданных...
Файл лога: C:\tmp\ETW\pktmon_curl_http_capture.etl (События не потеряны)
PS C:\tmp\ETW> pktmon etl2pcap C:\tmp\ETW\pktmon_curl_http_capture.etl
Обработка...

Всего пакетов:       11
Количество потерянных пакетов: 0
Отформатировано пакетов:   11
Отформатированный файл:    C:\tmp\ETW\pktmon_curl_http_capture.pcapng

Проблема

Когда я открыл файл .pcapng в Wireshark, все пакеты были интерпретированы как кадры Ethernet (Ethernet II), а не TCP/IP пакеты следующим образом:

> tshark.exe -r "C:\tmp\ETW\pktmon_curl_http_capture.pcapng"
    1   0.000000 d5:fb:7b:b4:14:4f → 08:01:00:80:cc:e1 0x8a95 109 Ethernet II
    2   0.002250 8a:95:c5:cc:cc:e1 → 88:42:2c:00:14:4f 0xd5fb 111 Ethernet II
    3   0.006914 d5:fb:7b:b4:14:4f → 08:01:00:80:cc:e1 0x8a95 84 Ethernet II
    4   0.182243 8a:95:c5:cc:cc:e1 → 88:42:2c:00:14:4f 0xd5fb 86 Ethernet II
    5   0.182342 d5:fb:7b:b4:14:4f → 08:01:00:80:cc:e1 0x8a95 72 Ethernet II
    6   0.182504 d5:fb:7b:b4:14:4f → 08:01:00:80:cc:e1 0x8a95 176 Ethernet II
    7   0.357137 8a:95:c5:cc:cc:e1 → 88:42:2c:00:14:4f 0xd5fb 74 Ethernet II
    8   0.422218 8a:95:c5:cc:cc:e1 → 88:42:2c:00:14:4f 0xd5fb 311 Ethernet II
    9   0.422221 8a:95:c5:cc:cc:e1 → 88:42:2c:00:14:4f 0xd5fb 88 Ethernet II
   10   0.422438 d5:fb:7b:b4:14:4f → 08:01:00:80:cc:e1 0x8a95 72 Ethernet II
   11   0.423482 d5:fb:7b:b4:14:4f → 08:01:00:80:cc:e1 0x8a95 72 Ethernet II

Содержимое HTTP-запроса/ответа, похоже, захвачено в файле .pcapng, но оно не распознается как TCP/IP пакеты.

> tshark.exe -r "C:\tmp\ETW\pktmon_curl_http_capture.pcapng" -Y "frame.number == 8" -V
Фрейм 8: 311 байт на проводе (2488 бит), 311 байт захвачено (2488 бит) на интерфейсе неизвестно, id 0
    id Интерфейса: 0 (неизвестно)
        Имя интерфейса: неизвестно
    Тип инкапсуляции: Ethernet (1)
    Время прибытия: Фев 26, 2025 23:30:00.334216000 Токийское стандартное время
    [Сдвиг времени для этого пакета: 0.000000000 секунд]
    Время эпохи: 1740580200.334216000 секунд
    [Разница во времени от предыдущего захваченного фрейма: 0.065081000 секунд]
    [Разница во времени от предыдущего отображенного фрейма: 0.000000000 секунд]
    [Прошедшее время с первого фрейма: 0.422218000 секунд]
    Номер фрейма: 8
    Длина фрейма: 311 байт (2488 бит)
    Длина захвата: 311 байт (2488 бит)
    [Фрейм помечен: Неверно]
    [Фрейм игнорируется: Неверно]
    [Протоколы в фрейме: eth:ethertype:data]
Ethernet II, Src: 8a:95:c5:cc:cc:e1 (8a:95:c5:cc:cc:e1), Dst: 88:42:2c:00:14:4f (88:42:2c:00:14:4f)
    Направление: 88:42:2c:00:14:4f (88:42:2c:00:14:4f)
        Адрес: 88:42:2c:00:14:4f (88:42:2c:00:14:4f)
        .... ..0. .... .... .... .... = LG бит: Глобально уникальный адрес (заводская настройка)
        .... ...0 .... .... .... .... = IG бит: Индивидуальный адрес (одноадресный)
    Источник: 8a:95:c5:cc:cc:e1 (8a:95:c5:cc:cc:e1)
        Адрес: 8a:95:c5:cc:cc:e1 (8a:95:c5:cc:cc:e1)
        .... ..1. .... .... .... .... = LG бит: Локально управляемый адрес (это НЕ заводская настройка)
        .... ...0 .... .... .... .... = IG бит: Индивидуальный адрес (одноадресный)
    Тип: Неизвестный (0xd5fb)
Данные (297 байт)

0000  7b b4 cc e1 d5 fb 7b b0 90 82 80 00 aa aa 03 00   {.....{.........
0010  00 00 08 00 45 00 01 15 46 d2 40 00 f7 06 4c a6   [email protected].
0020  2c d1 18 85 c0 a8 e9 6b 00 50 e4 bf a7 60 bc 6b   ,......k.P...`.k
0030  35 78 58 df 50 18 00 6a 2e 9e 00 00 48 54 54 50   5xX.P..j....HTTP
0040  2f 31 2e 31 20 32 30 30 20 4f 4b 0d 0a 44 61 74   /1.1 200 OK..Dat
0050  65 3a 20 57 65 64 2c 20 32 36 20 46 65 62 20 32   e: Wed, 26 Feb 2
0060  30 32 35 20 31 34 3a 32 39 3a 35 39 20 47 4d 54   025 14:29:59 GMT
0070  0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20   ..Content-Type:
0080  74 65 78 74 2f 68 74 6d 6c 3b 20 63 68 61 72 73   text/html; chars
0090  65 74 3d 75 74 66 2d 38 0d 0a 43 6f 6e 74 65 6e   et=utf-8..Conten
00a0  74 2d 4c 65 6e 67 74 68 3a 20 31 34 0d 0a 43 6f   t-Length: 14..Co
00b0  6e 6e 65 63 74 69 6f 6e 3a 20 6b 65 65 70 2d 61   nnection: keep-a
00c0  6c 69 76 65 0d 0a 53 65 72 76 65 72 3a 20 67 75   live..Server: gu
00d0  6e 69 63 6f 72 6e 2f 31 39 2e 39 2e 30 0d 0a 41   nicorn/19.9.0..A
00e0  63 63 65 73 73 2d 43 6f 6e 74 72 6f 6c 2d 41 6c   ccess-Control-Al
00f0  6c 6f 77 2d 4f 72 69 67 69 6e 3a 20 2a 0d 0a 41   low-Origin: *..A
0100  63 63 65 73 73 2d 43 6f 6e 74 72 6f 6c 2d 41 6c   ccess-Control-Al
0110  6c 6f 77 2d 43 72 65 64 65 6e 74 69 61 6c 73 3a   low-Credentials:
0120  20 74 72 75 65 0d 0a 0d 0a                         true....
    Данные: 7bb4cce1d5fb7bb090828000aaaa03000000080045000115…
    [Длина: 297]

Вопрос

Как Wireshark может интерпретировать пакеты, захваченные с помощью pktmon, как пакеты TCP/IP вместо Ethernet-кадров?

Ответ или решение

Для исследования проблемы, связанной с тем, что Wireshark интерпретирует пакеты, захваченные с помощью pktmon, как Ethernet-кадры вместо TCP/IP-пакетов, необходимо сначала понять, как работают оба инструмента и в чем может быть причина такой интерпретации.

Теория

Wireshark и Ethernet кадры

Wireshark — это мощный инструмент для анализа сетевого трафика, который способен интерпретировать пакеты на разных уровнях модели OSI. Ethernet кадры находятся на канальном уровне (Layer 2) и могут содержать различные виды данных, включая IP-пакеты, которые находятся на сетевом уровне (Layer 3). Под Ethernet II подразумевается формат кадра Ethernet для работы в сетях без 802.2 LLC, который является наиболее распространенным. Формат кадра включает в себя MAC-адреса отправителя и получателя, тип протокола и данные.

pktmon и его особенности

Pktmon — это встроенный в Windows инструмент мониторинга пакетов, позволяющий захватывать и записывать сетевой трафик. Основной компонент, с которым работает pktmon в вашем случае, это драйвер Intel(R) Wireless-AC 9560 160MHz. Pktmon создает файл формата .etl, который затем преобразуется в .pcapng для анализа в Wireshark. Важно отметить, что pktmon записывает весь сетевой трафик, включая Ethernet кадры, а не только пакеты TCP/IP, что может быть причиной неправильной интерпретации в Wireshark.

Пример

В вашем сценарии вы используете следующее:

  1. Захват пакетов с помощью команды pktmon:
    pktmon start --capture --comp 17 --pkt-size 0 --trace -p Microsoft-Windows-TCPIP --file-name C:\tmp\ETW\pktmon_curl_http_capture.etl
  2. Преобразование .etl в .pcapng:
    pktmon etl2pcap C:\tmp\ETW\pktmon_curl_http_capture.etl

После открытия полученного файла в Wireshark, все пакеты воспринимаются как Ethernet кадры. Кажется, что содержимое HTTP-запросов и ответов присутствует, но не разбирается должным образом как TCP/IP.

Применение

Возможные причины и решения:

  1. Тип протокола: Судя по выводу Wireshark, тип протокола определяется как Unknown (0xd5fb). Это указывает на то, что Wireshark не понимает тип сетевого протокола, указанный в Ethernet кадре. Вероятно, pktmon записал пакеты с неидентифицируемым типом. Попробуйте проверить настройки захвата в pktmon или исследовать возможность добавления пользовательских определений протоколов в Wireshark.

  2. Конвертация данных: Убедитесь, что конвертация файлов из .etl в .pcapng проходит корректно. Возможно, потребуется обновление инструмента pktmon или исследование новых версий, чтобы убедиться, что в процессах конвертации не теряются данные, относящиеся к IP-протоколу.

  3. Обновление Wireshark: Иногда проблема может заключаться в версии ПО. Попробуйте проверить возможность обновления Wireshark, так как более новые версии могут содержать исправления ошибок, связанных с интерпретацией подобных файлов.

  4. Дополнительные фильтры в pktmon: Если вы можете, добавьте более точные фильтры для захвата только интересующих вас протоколов. Это может уменьшить количество необработанных данных в итоговом файле.

  5. Ручная корректировка конфигурации Wireshark: Проверьте, можно ли вручную указать Wireshark на интерпретацию захваченных данных как TCP/IP на основе содержимого данных пакетов.

Дополнительный анализ

Чтобы более детально разобраться в проблеме, выполните следующее:

  • Используйте команду -V в tshark для детального просмотра информации по каждому кадру и исследуйте.
  • Используйте анализаторы, которые позволили бы расшифровать непонятные типы протоколов, так как это могут быть специфические внутренние данные вашей сети.

Кратко, проблема может быть связана как с самим процессом захвата и преобразования данных pktmon, так и с конфигурацией Wireshark для анализа непонятных типов протоколов. Как совет, старайтесь адаптировать оба инструмента к вашим специфическим нуждам через расширенные настройки и обновления.

Оцените материал
Добавить комментарий

Капча загружается...