Есть реализованный драйвер протокола. При отправке сообщения с 3го кольца передается буфер с данными, на него накладывается IP и Ethernet заголовки, при этом в поле Protocol Field IP заголовка прописывается определенное число, не входящее в число известных (well-known), например 0xAA.
При принятии происходит всё наоборот, и принятый буфер передается клиенту протокола. Проблема заключается в том, что так как в Ethernet заголовке верхний протокол — IP, то, по всей видимости, стандартный драйвер стека TCP/IP винды также получает принятый пакет и пытается его обработать. В результате, встретив в поле Protocol Field неизвестное значение (0xAA), отправителю посылается ICMP с кодом 3 (Protocol Unreachable).
Получается, что на каждый принятый пакет, помимо ответа от моего протокола посылается ещё и icmp пакет, что, естественно, недопустимо.
(выделенное курсивом — мои догадки, если я не правильно думаю, поправьте, пожалуйста...)
За основу протокола был взят ddk'шный (версии 3790.1830) ndisprot. ОС — WinXP SP3 (Ndis 5.1).
Просьба подсказать, есть ли способ решения этой проблемы... например, каким-то образом сказать NDIS'у, что пакет обработан, дабы не заставлять ICMP ругаться (хотя по идее об этом говорит возврат SUCCESS кода из ProtReceive)... Пока что я вижу только способ — взять за основу passthru и в нем отслеживать, отдавать пакеты стеку TCP/IP или обрабатывать самому, но хотелось бы решение, не столь меняющее архитектуру драйвера...
Здравствуйте, Аноним, Вы писали:
А>А зачем нужен альтернативный IP драйвер? Почему вы не хотите использовать сырой сокет?
Я тоже задавался этим вопросом, но нужен именно такой вариант.
Проблема, видимо, в том, что клиент для драйвера уже написан и его переписывать нельзя.
Раньше функционал протокола был реализован в драйвере минипорта и проблем не было, т.к. минипорт получал пакет из сети и обрабатывал IRP'ы на чтение, не дергая NDIS.
Сделано это некрасиво, поэтому и было решено разделить функционал и написать отдельно драйвер протокола и минипорта.
Здравствуйте, Cloudo, Вы писали:
C>Есть реализованный драйвер протокола. При отправке сообщения с 3го кольца передается буфер с данными, на него накладывается IP и Ethernet заголовки, при этом в поле Protocol Field IP заголовка прописывается определенное число, не входящее в число известных (well-known), например 0xAA.
C>При принятии происходит всё наоборот, и принятый буфер передается клиенту протокола. Проблема заключается в том, что так как в Ethernet заголовке верхний протокол — IP, то, по всей видимости, стандартный драйвер стека TCP/IP винды также получает принятый пакет и пытается его обработать. В результате, встретив в поле Protocol Field неизвестное значение (0xAA), отправителю посылается ICMP с кодом 3 (Protocol Unreachable).
C>Получается, что на каждый принятый пакет, помимо ответа от моего протокола посылается ещё и icmp пакет, что, естественно, недопустимо.
C>(выделенное курсивом — мои догадки, если я не правильно думаю, поправьте, пожалуйста...)
C>За основу протокола был взят ddk'шный (версии 3790.1830) ndisprot. ОС — WinXP SP3 (Ndis 5.1).
C>Просьба подсказать, есть ли способ решения этой проблемы... например, каким-то образом сказать NDIS'у, что пакет обработан, дабы не заставлять ICMP ругаться (хотя по идее об этом говорит возврат SUCCESS кода из ProtReceive)... Пока что я вижу только способ — взять за основу passthru и в нем отслеживать, отдавать пакеты стеку TCP/IP или обрабатывать самому, но хотелось бы решение, не столь меняющее архитектуру драйвера...
На клиенте надо поставить фильтр.Попробуй использовать WFP.
Здравствуйте, eagersh, Вы писали: E>На клиенте надо поставить фильтр.Попробуй использовать WFP.
Из MSDN:
Windows Filtering Platform (WFP) is a new architecture in Windows Vista and Windows Server 2008 that enables independent software vendors (ISVs) to filter and modify TCP/IP packets, monitor or authorize connections, filter Internet Protocol security (IPsec)-protected traffic, and filter remote procedure calls (RPCs)...
Здравствуйте, Cloudo, Вы писали:
C>Здравствуйте, eagersh, Вы писали: E>>На клиенте надо поставить фильтр.Попробуй использовать WFP.
C>Из MSDN: C>
C>Windows Filtering Platform (WFP) is a new architecture in Windows Vista and Windows Server 2008 that enables independent software vendors (ISVs) to filter and modify TCP/IP packets, monitor or authorize connections, filter Internet Protocol security (IPsec)-protected traffic, and filter remote procedure calls (RPCs)...
C>В моем случае ОС: WinXP SP3...
Тогда поставь intermediate NDIS драйвер. Он делает binding на нижнем уровне с miniport NDIS drivers и на верхнем с protocol NDIS drivers. То есть он будет получать an Ethernet packet перед tcpip.sys. Посмотри пример /src/network/ndis/passpthru из WDK.
Здравствуйте, eagersh, Вы писали:
E>Тогда поставь intermediate NDIS драйвер. Он делает binding на нижнем уровне с miniport NDIS drivers и на верхнем с protocol NDIS drivers. То есть он будет получать an Ethernet packet перед tcpip.sys. Посмотри пример /src/network/ndis/passpthru из WDK.
Я об этом и писал в старт-топике...
Пока что я вижу только способ — взять за основу passthru и в нем отслеживать, отдавать пакеты стеку TCP/IP или обрабатывать самому, но хотелось бы решение, не столь меняющее архитектуру драйвера...
К сожалению, другого способа, видимо, нет. Смотрел исходники NDISа в win2k и в ReactOS'e. Функция IndicateReceivePacket, вызываемая минипортом, когда на тот приходит пакет, пробегается по списку всех забинденных на адаптер протоколов и вызывает соответствующие ReceiveHandler.
