我已经找到问题所在，目前已经解决passthru的移植问题

前不久我一直处于郁闷状态：转业问题一直没有消息，
因此一直无法定回家的时间，passthru的移植又产生了
拨号问题。师兄让我帮他写c#的数据结构算法移植。各种
事情交杂，我几乎没有心情安坐下来学习和工作。

但是今天无聊的翻看ddk document，无意中发现里面有
如下的一段描述：
An intermediate driver bound to a WAN-capable NIC must also make the following set-information requests:

OID_WAN_PROTOCOL_TYPE to inform the underlying miniport driver of the protocol\'s type. The type is supplied as a single-byte, network-level protocol identifier.
OID_WAN_HEADER_FORMAT to inform the underlying miniport driver of the header format of the packets it sends

然后我去仔细的翻看关于协议驱动程序的描述以及wan adapter
的描述，终于找到了一点点线索。原来TAPI在进行连接的时候
需要通过ndiswan，而ndiswan在协商协议类型的时候需要从
协议那里获得协议信息。这个信息就是通过ndisrequest
由协议驱动程序提供给ndiswan的。

于是乎，5分钟之后，我解决了此问题。

下午我会继续做些试验，仔细了解一下pppmac的工作过程，
因为我发现pppmac和ndiswan的工作原理似乎颇有不同，至少
我发现连接映射是很不一样的，涉及到绑定和信息交互
也不一样。相比起来，2k的ndiswan设计的时候似乎更为
复杂，支持的功能更多。

如果在回家之前有空，也许会写一篇帖子完整的向大家介绍
整个移植中遇到的问题和心得体会。

ps：passthru for winxp直接支持wan的绑定，但是代码里面
有个错误，会引起ASSERT。大家可以看一下ptbindadapter
和mpinialize，会发现对于ndismediumwan的处理不对，当
bind ndiswan的时候，ndisopenadapter的调用会返回selectmedum
=3，也就是ndismedumwan，但是在mpinilize的时候并不
修改这个值，只是欺骗上层（tcp/ip），这是一个802.3，
但是当ptreceive的时候，在那个switch里面，这个值
还是ndismediumwan，因此会发生问题。简单的修改方法
是在mpinilize里面加上padapt->medium=medium；（
在发现medium == ndismediumwan的时候）
或者,在switch里面加上一个case ndismediumwan:
然后ndismethindicatepacket（...）。在ptreceivecomplete
里面同样处理。

版主：
现在还没回家呀！家离北京远不远？
我看版主晚上工作到4.00，真是让人佩服！
我现在下想在一个很短的时间完成数据包在网卡和拨号网络适陪器之间的转发，不知道可能不可能
，能否给一些建议！

呵呵！真是让我少走了很多弯路啊！谢谢版主了

版主：
现在还没回家呀！家离北京远不远？
我看版主晚上工作到4.00，真是让人佩服！
我现在下想在一个很短的时间完成数据包在网卡和拨号网络适陪器之间的转发，不知道可能不可能
，能否给一些建议！

我这篇文章并非4:00发的，这是这个系统的一个bug。
我家离北京大致向南20个小时。我想还是比较远的:-)。

bridge for nt我没有做过，但是我想应该不难吧，我没有
仔细的想过里面的细节和可能会遇到的问题。在ptrecievepacekt
或者ptreceive调用ndissend？速率不匹配问题？

谢谢版主！
我如果做出来了，我一定写一篇心得体会，到时有麻烦需要你的帮忙！
祝版主以及所有驱动开发网上的兄弟，
新年快乐，万事如意，
身体健康，多多进步！

斑竹已经在家幸福的过年了。
在这儿祝福您了！同喜同贺！
:-)