请教斑竹：关于同一层次的驱动共存的问题

当加密模块完成以后，我的win200下的IPSEC驱动已经基本完成了，
但是，最近在调试的过程中发现了一些问题，比如：驱动程序的共存问题，我搜索了本站的帖子，发现没有人提这个问题。我给分，大家讨论一下。
是这样的，我发现我的驱动起来以后，首先是Sniffer抓包不正常了，绑定到物理网卡上的sniffer不能抓到全部包，我通过在两台PC中使用HUB，然后再使用另一台PC的sniffer来抓包，所有的IPSEC包都抓到了。但在两台机器上却始终没有办法抓全。
然后我想到做到同一层次的驱动可能会有冲突，于是，我装上了Vmware，这个软件可以肯定是做在IM层的，我的IPSEC驱动也是中间层的，然后，发现已经不正常了，装上就使机器重新启动。
我认为是我驱动有问题，于是使用了PGP的IPSEC client，发现Vmware和PGP都不可用了，并且，当我卸载掉Vmware后，PGP没有办法卸载了。可以肯定的是PGP也是做在中间层的。
于是，我又重新装上我的驱动，这个时候，机器上只有PGP，发现了KeDebugEx错误，并且没有办法屏蔽掉该错误。
我想这个问题完全有可能出在我的驱动的上面，但是，如果sniffer是使用的winpcap，我看了是一个协议驱动，没有HOOK，IM是不应该影响它的。
最后，希望大家分析一下这个问题，并且能够给出分析的思路和方法，共同探讨吧。。。
分。。。。不是问题的

sniffer收不到完整的包肯定和你的处理有关系，特别是向协议层提交的时候。

sniffer使用的就是一个协议驱动，这个应该是他们自己做的就可以了，与PGP没有什么关系。

你如何确定说pgp和VMware都是IM？这个看一下他们的驱动的inf文件就知道了。VMware如果是一个IM的话也应该是一个mux。

首先还是感谢mike的回答，但是你似乎没有看清楚我的问题，是吗？我可以通过各种渠道知道PGP是否是一个中间层驱动，其中也包含你所说的办法，它当然可以是一个MUX，只要它愿意虚拟成一张网卡。我的意思是，是使用PGP仍然会导致sniffer抓包的不全，这个应该和我没有关系的。
我始终都不明白为什么协议层驱动跟中间层有什么关系，当协议层驱动绑定到物理网卡后，就维护了该张网卡到此协议的一个通道，我认为这个时候该驱动就应该能够得到网卡上来的全部的包，否则使用ethernet软件组成的PPP包就不应该被sniffer抓到！因为PPP是一个虚拟网卡，当包到协议层以前就已经被剥掉了PPP头，而如果没有其它驱动的时候，sniffer看到的当然就只是IP包了。但事实是sniffer能够看到PPP包，这个也就跟gjplant对PACKET和protocol hook的描述，这个当然也是猜测了。
我不知道是否在同一台机器上装上属于同一个层次的驱动是否会有问题，但是我以前开发的放火墙在这里仍然是有问题的，那是做在protocol的，不知道mike在向上传递包的时候是否应该注意什么呢？希望大家多多讨论

如果你装一个空的passthru，sniffer是可以收到完整的packet的。

有可能是sniffer在调用transfer的时候的问题。

装了imd以后，其实TCP已经不知道真实的网卡了，知道的只是passthru的网卡，只不过passthru的虚拟网卡直接把所有的查询都转到了真实的网卡上，所以你在TCP看到的还是真实网卡的信息。这只是一个假象。如果你装了mux，就会发现TCPIP不知道真实的网卡了，看到的只是mux的网卡。

sniffer抓到ppp的包只能是在2k下吧，他是bind到了wanip的那个设备上的吧？ppp的头是在ndiswan里面剥掉的。

同一层次上的驱动的问题，passthru有三个层次，每个层次只能装一个，别的驱动应该是没有限制的。

如果你装一个空的passthru，sniffer是可以收到完整的packet的。

有可能是sniffer在调用transfer的时候的问题。

装了imd以后，其实TCP已经不知道真实的网卡了，知道的只是passthru的网卡，只不过passthru的虚拟网卡直接把所有的查询都转到了真实的网卡上，所以你在TCP看到的还是真实网卡的信息。这只是一个假象。如果你装了mux，就会发现TCPIP不知道真实的网卡了，看到的只是mux的网卡。

sniffer抓到ppp的包只能是在2k下吧，他是bind到了wanip的那个设备上的吧？ppp的头是在ndiswan里面剥掉的。

同一层次上的驱动的问题，passthru有三个层次，每个层次只能装一个，别的驱动应该是没有限制的。

mike,看来只有我和你在关注这个问题，首先我必须要说，在98和2K下sniffer都能够抓到完整的PPP包，这个我已经做过实验，而且，在98下我的驱动是得不到PPP包的，也就是说
在98下，PPP的驱动做到了我的下面，
2K下面我没有实验过，这个倒是可以尝试一下。


关于只是安装一个passthru，我也试过了，没错，它的确是可以通起来，而且Sniffer也可以正常的工作，但是不知道你注意没有，
当sniffer起来以后，如果你是PING包，抓到的包总是多了一个，
你可以马上做这个实现，用的是sniffer4.5。
而且，还有一个有趣的现象，你可以在passthu中看到，
上面的协议（姑且认为它是协议），在不断进行NdisRequest，
在QueryInformation中可以发现这些OID，这些OID在NDIS中有一些可以看到它的定义。有些是没有的。而且还有个现象
在passthru卸载的时候会出现问题。


关于你说绑定的问题，我其实不是很明白你的意思，如果你说的是sniffer的选择绑定，我可以说，它只是需要绑定到物理网卡上就可以抓到PPP包了。

当然，我认为我的想法也有很大的问题，比如，我做了试验，当我在IM层丢掉了包以后，的确sniffer得不到包，我已经很难想清楚这个现象了，而如果真的protocol跟网卡之间可以有一个专用的通道
这个现象是不应该出现的。

我想IM的RegisterProtocol和绑定跟协议驱动的可能会有区别，这个自然没办法用gjplant的说法来解释了

你知道怎样可以叫老Hu来关注一下这个问题吗？

大家关注呀，我这里顶一下，分不错了呀？？？？

mike,看来只有我和你在关注这个问题，首先我必须要说，在98和2K下sniffer都能够抓到完整的PPP包，这个我已经做过实验，而且，在98下我的驱动是得不到PPP包的，也就是说
在98下，PPP的驱动做到了我的下面，
2K下面我没有实验过，这个倒是可以尝试一下。


关于只是安装一个passthru，我也试过了，没错，它的确是可以通起来，而且Sniffer也可以正常的工作，但是不知道你注意没有，
当sniffer起来以后，如果你是PING包，抓到的包总是多了一个，
你可以马上做这个实现，用的是sniffer4.5。
而且，还有一个有趣的现象，你可以在passthu中看到，
上面的协议（姑且认为它是协议），在不断进行NdisRequest，
在QueryInformation中可以发现这些OID，这些OID在NDIS中有一些可以看到它的定义。有些是没有的。而且还有个现象
在passthru卸载的时候会出现问题。


关于你说绑定的问题，我其实不是很明白你的意思，如果你说的是sniffer的选择绑定，我可以说，它只是需要绑定到物理网卡上就可以抓到PPP包了。

当然，我认为我的想法也有很大的问题，比如，我做了试验，当我在IM层丢掉了包以后，的确sniffer得不到包，我已经很难想清楚这个现象了，而如果真的protocol跟网卡之间可以有一个专用的通道
这个现象是不应该出现的。

我想IM的RegisterProtocol和绑定跟协议驱动的可能会有区别，这个自然没办法用gjplant的说法来解释了

你知道怎样可以叫老Hu来关注一下这个问题吗？

如果只binding到无理网卡抓到ppp报文，除非你是adsl拨号上网的，否则不可能。

协议层是通过bind关系知道下面的miniport的，整个的工作过程通过ndis来协调的。这个你可以好好看一下ddk。

你说的多一个包，应该是装了passthru以后是两个echo一个reply吧？这个问题我也在想，应该是发包的时候经过了两个miniport有关系。

其实你可以做一个协议驱动，在这个协议里面把网卡设置成混杂模式，你就可以收到所有到达网卡的包了。

老胡现在在泡帝国空军的MM，这个你看他的签名就知道了，哈哈，估计是没有时间来了吧：）

Mike,我的确事作了这个实验，而且，确实是
用Sniffer抓到了PPP包，这个问题我们先放到这里
以后再讨论。
再跟你讲一个问题，对于多个网卡得问题，你想过没有？
如果我又两个网卡，假如我只是想绑定第一块，第二块不绑定
我希望得是在网络邻居中第二个连接中都看不到绑定了，
我在protocolbindadapter中不让它绑定第二
块网卡，好，这一步没有问题。
但是，在这个函数完了以后，系统调用queryinformation，在
这个函数的参数中会有一个miniporthandle返回，接着
我查了这个handle的地址，二这个地址竟然是我绑定
第一块网卡所得到的Adapter的地址，从二使得在
第二块网卡上的绑定仍然是成功的
我达不到自己的目的，我就是想知道，如果我有几个
Adapter，NDIS对这几个网卡是怎么管理的？
不知道你明白我的意思没有？

你还是没有明白为什么你的ptbindadapt会被调用，那是在安装的时候就已经建立起来的绑定关系了，所以你的ptbindadapter才会被调用，你这时候能怎么处理呢？？只能是向TCPIP返回一个虚假的adapter。

要想达到你的目的就要在安装的时候打断和第二块网卡的绑定关系。

也可以手工在网络属性里面把那个绑定关系去掉，把那个对号取消。

诶，mike,看来你听懂了我问题哟？我仔细阅读了你的话，我想你告诉我，你所谓的”打断“是什么意思呢？
所有的新的硬件都会被PNP枚举，也就是说protocolbindadapter函数的调用，是我们的驱动没有办法控制的。
我做了这个实验，在protocolbindadapter中什么都不做，在
网络属性里面仍然可以看到被装上，当然
网络是不通的。
设想一种情况吧，当我们的驱动加载后，数据必须要通过我的
驱动程序，我要负责这个转发！但是，如果把对号去掉
NDIS就屏蔽了我们的驱动，我就是想知道它是怎么屏蔽的，
我们自己来做这个操作，而不是通过用户把对号去掉。毕竟，
我们的是产品嘛！
当然这个操作可能是在API中来完成的，但是，我找不到这个东西，
不知道你有没有资料？

诶，mike,看来你听懂了我问题哟？我仔细阅读了你的话，我想你告诉我，你所谓的”打断“是什么意思呢？
所有的新的硬件都会被PNP枚举，也就是说protocolbindadapter函数的调用，是我们的驱动没有办法控制的。
我做了这个实验，在protocolbindadapter中什么都不做，在
网络属性里面仍然可以看到被装上，当然
网络是不通的。
设想一种情况吧，当我们的驱动加载后，数据必须要通过我的
驱动程序，我要负责这个转发！但是，如果把对号去掉
NDIS就屏蔽了我们的驱动，我就是想知道它是怎么屏蔽的，
我们自己来做这个操作，而不是通过用户把对号去掉。毕竟，
我们的是产品嘛！
当然这个操作可能是在API中来完成的，但是，我找不到这个东西，
不知道你有没有资料？
 

用一个dll在安装的时候来做这个工作。你可以先看一下snetcfg的那个例子，用来在命令行安装的，然后还有一个notify object的例子，应该是dll，可以处理这些bind的关系的。

如果你装了最新的ddk，里面有一个例子可以给你演示系统的bind关系，并可以随时打断这个bind关系。好像叫bindview吧。
ddk里面有一章是讲notify object，好好看看就会了。


如果你打断了和第二块网卡的bind关系，那么所有发往第二块网卡的数据和消息都接受不到了。
好运。

我在google的新闻组里发现了这些讨论
很多相关的东西，我想要仔细看一下才可以
继续我们的讨论，如果你有任何新的发现？？？
我时刻关注在这里