Wireshark под Windows: Есть ли способ захватить пакеты до того, как они будут отброшены специальными фильтрами?

У меня есть камеры GigabitEthernet Vision, которые используют Ethernet для связи. Протокол простой – UDP, но по причинам производительности (высокая пропускная способность пакетов, вызывающая нагрузку на ЦП) производитель использует фильтрационный драйвер, который предотвращает отображение этих пакетов во время захвата с помощью WinPCap/Wireshark.

Программное обеспечение, которое поставляется с камерами, требует фильтрационного драйвера для работы (нет простого обратного соединения UDP-Socket), и я хотел бы проанализировать его трафик. Я хотел бы избежать необходимости захватывать данные, используя дополнительное оборудование, и предпочитаю программное решение этого вопроса.

Вопрос: Есть ли способ приоритизировать WinPCap, чтобы он обрабатывал пакеты перед фильтрационным драйвером?

Информация о системе:

• ОС: Windows 10 (64-бит)
• Программное обеспечение: Wireshark 2.4.4[-0-g90a7ve11a4]
• Драйвер захвата: WinPCap v4.1.3 (версия packet.dll 4.1.0.2980)
• RealTek: USB-GbE-адаптер (версия драйвера 10.7.218.2016)

Скриншот конфигурации адаптера (на немецком, извините):

Это скриншот из настроек моего сетевого интерфейса (отмеченный драйвер ‘Teledyne DALSA Sapera GigE Vision Filter Driver’ – это тот, который нам нужен).

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

Если камеры подключены к коммутатору, вы можете настроить зеркальный порт (зеркалить порт, к которому подключена камера, на порт, в который вы подключаете машину для захвата Wireshark).

Если камеры подключены напрямую к компьютеру, на котором вы запускаете Wireshark, убедитесь, что TCP Chiminey отключен.

Вот несколько ссылок, которые, кажется, связаны с попыткой решить эту конкретную проблему.

https://networkengineering.stackexchange.com/questions/34961/why-does-wireshark-not-show-all-traffic-especially-gvsp-data

https://www.wireshark.org/docs/dfref/g/gvsp.html

https://wiki.wireshark.org/CaptureSetup/Offloading#TCP_Chimney

Также было бы полезно, если бы вы предоставили больше информации о камере (т.е. какая модель(и) камеры?) и вашей сетевой топологии (например, камеры подключены к компьютеру, на котором вы запускаете Wireshark, к концентратору или к коммутатору?).

Редактировать: На самом деле вы спрашиваете, можно ли вручную изменить порядок записей каталога Winsock (поставщика структурированных сервисов). Запустив netsh winsock set /?, вы сможете увидеть, какие у вас есть варианты для прямой настройки Winsock. Из всего, что я вижу, у вас нет возможности изменить порядок LSP.

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753591(v=ws.10)

https://msdn.microsoft.com/en-us/library/windows/desktop/gg581810(v=vs.85).aspx

https://blog.malwarebytes.com/cybercrime/2014/10/changes-in-the-lsp-stack/

У меня была такая же проблема с фильтрационным драйвером Matrox Imaging Library, и Wireshark не мог захватывать пакеты. Оказалось, netsh trace может захватывать данные. К сожалению, это медленно и занимает много дискового пространства и требует много времени для сохранения, но это позволяет увидеть трафик. Я захватывал только несколько секунд с максимальным размером файла 128 МБ, потому что это все, что мне нужно, чтобы понять, что происходит. Вам нужно конвертировать файл etl в файл pcapng, затем версия Wireshark 3.6+ может его прочитать, Microsoft создал etl2pcapng для преобразования файла: https://github.com/microsoft/etl2pcapng.

Инструкции изложены здесь https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/converting-etl-files-to-pcap-files/1133297:

netsh trace start capture=yes tracefile=c:\temp\file.etl maxsize=1024 filemode=circular
netsh trace stop
etl2pcapng.exe file.etl newfile.pcapng

Затем вы можете открыть файл pcapng в Wireshark, и он будет отображаться как обычно.

Берегитесь: etl2pcapng добавит комментарий, показывающий PID и поток “текущего процесса”, но это в основном бесполезные данные для меня. Человек, который написал эту функцию, сделал об этом блог-пост здесь https://blog.didierstevens.com/2020/01/28/etl2pcapng-support-for-process-ids, и включает в себя этот ответ от Microsoft,

Содержимое выходного файла pcapng будет содержать комментарий в каждом пакете, указывающий PID текущего процесса, когда пакет был записан. ПРЕДУПРЕЖДЕНИЕ: это часто не совпадает с фактическим PID процесса, который вызвал отправку пакета или к которому пакет был доставлен, поскольку провайдер захвата пакетов часто работает в DPC (который работает в произвольном процессе). Пользователь должен помнить об этом, используя информацию PID.

Для меня это показывало, казалось бы, случайные процессы, оказывается, эти данные принимаются сетевым стеком с помощью отложенного вызова процедуры, а DPC фактически повторно использует контекст выполнения потока, который был прерван для обработки захвата пакетов! Таким образом, notepad.exe может быть прерван, и его собственный контекст выполнения затем используется “провайдером захвата пакетов”, это приводит к тому, что PID notepad.exe отображается в результирующем .pcapng файле, полученном из данных netsh trace, хотя он в противном случае не имеет отношения (весьма интересно видеть, что было прервано и когда для обработки этого пакета).