气愤的是，SendPacketsHandler 之后，NdisSendComplete还会被调用，状态是0, STATUS_SUCCESS，看那个包，依然是假地址...   真能骗人;  

不会真的是Modem在拦吧？

ISP拦？ 假地址是在真实的地址上+1，ISP怎么拦啊

adsl isp可能不会被路由的 你用 2003测试下看看

我一直都是在 Windows Server 2003 Enterprise Edition Services Pack 2 下测试

根据我有限的知识， NIC驱动的 SendPacketsHandler ， 已经很接近 NdisRawWritePortUchar 了，而NdisRawWritePortUchar  已经写硬件端口了，期间并没有多少NDIS的库函数的调用，我找不到NDIS怎么拦的；

如果NIC驱动在拦(就算是这样)，但如果人家的网卡有自己的驱动，并不用你微软提供的通用驱动呢？你怎么拦。

所以，还是在NDIS库里拦吧... 但如果在NDIS库拦的，必须在人家驱动在 SendPacketsHandler  - NdisRawWritePortUchar 的过程中调用了某个特定的库函数，你才能拦， 并没有规定在这个过程中一定要调用哪个NDIS库函数才能写数据，我看了ne2000的代码(虽然ne2000老掉牙了)，在 SendPacketsHandler  - NdisRawWritePortUchar  的过程中基本就没有调用过什么NDIS函数库；

唉，我等菜鸟，是没办法的了；

再以有限的知识发下唠嗦，以 ne2000 为例,

SendPacketsHandler 注册为 Ne2000Send;

ne2000send将包插入待发送队列，这个队列是 ne2000维护的，不是NDIS维护的，所以NDIS做不了手脚；

接着调用 Ne2000DoNextSend,  这里有个 NdisQueryPacket ，查询下包长度， 我开始以为这个是NDIS库函数，结果不是; 接着一系列的对包队例的检查啊什么的..反正没有NDIS的参与，接着 CardCopyDownPacket  CardCopyDown CardStartXmit 。。等， 这些函数都不是NDIS的，而是ne2000的， 这些函数都只是调用 NdisRawWritePortUchar ， 而这个 NdisRawWritePortUchar， 根本就是一个宏， out 端口而已,  在最最最后， 很关键， 调用了 NdisMSendComplete ， 发送完成了；

整个过程，没有什么NDIS库函数的参与；

我只是想说： 在 SendPacketsHandler 这里， 包里的数据， IP头的源地址还是假的，而这期间，并不需要调用什么NDIS库函数，就可以把包扔进网卡芯片中，NDIS是怎么拦的，难道一定要依赖人家的网卡驱动在这个过程中调用了你NDIS的某些特定的函数的时候，你才能拦吗？

值得一说的是， 在ring3用假地址把包发下去，win2003会把假地址改为真实的地址，再把包往下发； 但如果到了SendPacketsHandler 这里，源地址还是假的， 系统不会改回来，这证明包如果到了SendPacketsHandler这里， 就已经绕了第一层(第n层？)的过滤，那么，在下下下下层，还存在检查机制，这个检查制机不再帮你改假地址，而是阻止你发送？？？？