NDIS и драйвер минипорта

Драйверы минипорта NDIS, как и многие низкоуровневые драйверы, предназначены для взаимодействия с оборудованием. Ответственность минипорта состоит в том, чтобы принимать отправляемые пакеты от ОС, преобразовывать их в любой формат, требуемый аппаратным обеспечением, и давать указание аппаратному обеспечению отправить пакет по сети.

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

Вместо этого образец «netvmini» в WDK является поддельным драйвером. Это означает, что он притворяется, что у него есть настоящее оборудование, но на самом деле все это ложь. Когда ОС отправляет пакеты на netvmini, драйвер netvmini просто передает эти пакеты на любые другие адаптеры мини-порта netvmini, установленные на этом компьютере. (По сути, установка двух адаптеров netvmini на одном компьютере имитирует то, что произошло бы, если бы у вас было два реальных адаптера, подключенных к одному и тому же концентратору Ethernet.) Таким образом, в ASCII-арте это происходит, если вы устанавливаете два адаптера netvmini в одной системе. :

       TCPIP                       TCPIP                      TCPIP
         |                           |                          |
Real physical miniport        Your netvmini #1           Your netvmini #2
         |                           \                          /
   [The Internet]                     [The netvmini virtual hub]

Как мы надеемся, иллюстрирует ASCII-арт, ваши адаптеры netvmini не имеют никакого пути к Интернету. Таким образом, ваш драйвер не получит «настоящий» IP-адрес, который может маршрутизироваться в Интернет, пока вы не добавите информацию о своем оборудовании. До тех пор Windows будет просто пытаться отправлять ARP и HTTP-запросы, которые никуда не уйдут.

Чтобы ответить на ваши конкретные вопросы:

1. Сообщения из MPSendNetBufferLists печатаются каждый раз, когда ОС пытается отправить пакет. Поскольку ОС считает, что у вас есть реальное сетевое соединение, она предпримет несколько попыток его использовать. В конце концов, это должно немного успокоиться, когда все придут к выводу, что это бесполезная ссылка.

2. Запросы поступают от TCPIP. Если вы не хотите, чтобы TCPIP отправлял данные, отвяжите его от адаптера.

3. Вы можете определенно отправить данные на адаптер. На самом деле, вы заметили, что вы уже отправляете случайные HTTP-пакеты и т. д. Но данные на самом деле не попадут в Интернет, пока вы не научите драйвер общаться с вашим реальным оборудованием.

Если вы сидите и думаете: «Но у меня нет оборудования!», то вы можете создать какой-нибудь виртуальный минипорт. Виртуальные мини-порты похожи на netvmini в том смысле, что у них нет реального оборудования, но у них все же есть какой-то способ получить пакеты с машины. Например, мини-порты VPN, работающие на уровне 2 (например, L2TP), обычно устанавливают второй драйвер, драйвер протокола NDIS, который отправляет и получает данные из «настоящего» физического мини-порта. Затем виртуальный минипорт взаимодействует со своим протоколом всякий раз, когда ему нужно получить пакеты от машины. Результат:

        TCPIP
          |
  Your virtual miniport
          |
   Your NDIS protocol
          |
The real physical miniport
          |
     The Internet

Существуют альтернативные архитектуры; например, VPN, работающая на уровне 4 (например, SSTP), может решить открыть сокет WSK вместо реализации драйвера протокола NDIS:

        TCPIP
          |
  Your virtual miniport
          |
      WSK socket
          |
        TCPIP
          |
The real physical miniport
          |
     The Internet