Я исследую проблему с процессом, который выполняет IPC через сокет. Сокет обслуживается на IP-адресе сетевого адаптера локального компьютера, и соединение с IP-адресом сетевого адаптера локального компьютера осуществляется другим процессом на локальном компьютере.
Я ожидал, что это опустит сетевой стек Windows, по крайней мере, настолько, чтобы Wireshark мог видеть пакеты. Однако, похоже, это не так. Таким образом, я могу заключить, что IPC сокета занимает более высокое место в стеке [было бы интересно посмотреть, будут ли какие-либо средства трассировки событий Windows (ETW) видеть трафик как IP-кадр]. Это не важно для этого вопроса (поскольку это не stackoverflow).
Где WinPcap / Npcap «живет» в сетевом стеке, чтобы прослушивать и передавать пакеты в wirehark?
Я ориентирован на современные версии ОС Windows (клиент: 7+, 10+; сервер: 2008+, 2012+, 2016+). В частности, это клиент Windows 10.
Я действительно хочу знать, где в сетевом стеке принимается решение «возвращать» пакеты к хосту, а не отправлять их вниз по стеку.
Спасибо
Он находится на уровне IP, если не включен Fast Loopback, он находится на уровне TCP. Такие приложения, как Network Monitor или Wireshark, не работают из-за того, что сетевой стек Microsoft не оснащен инструментами для захвата трафика обратной связи.
"По умолчанию интерфейс обратной связи TCP перемещает локальный TCP-трафик через большую часть сетевого стека, включая AFD (который, по сути, является представлением режима ядра сокета TCP пользовательского режима), а также уровни, соответствующие TCP и IP. уровни протокола ".
В качестве альтернативы вы можете выполнить захват на уровне платформы фильтрации Windows (WFP) с помощью Microsoft Message Analyzer:
https://blogs.msdn.microsoft.com/winsdk/2014/08/15/rejoice-we-can-now-capture-loopback-traffic/