给我一份！！！
syuanyy@371.net

我再上传一次试试看。

[quote]给我一份！！！
syuanyy@371.net

我再上传一次试试看。
 [/quote]
再上传一次试试看!!!

怪不得大家都要呢，原来传了那么多次都没成功。

把文件名换成英文试试

下载不了呀？

请给我也发一份。多谢！！！！！！！！！！！

beyond1999@x236.net

我并没有上面的文档，只是研究所得。你可以到http://www.mikrotik.com
上down个pppoe for win2000的源程序来研究

我在这上面找了一个遍也没找到源程序，当真有的话，能给一个连接吗？

下不了呀，传给我一份吧！zhang_jiaqi@eyou.com

从本站下了也没法看那，word就打不开，说有非预期性的错误，麻烦给我传一下吧 :)

[quote]我并没有上面的文档，只是研究所得。你可以到http://www.mikrotik.com
上down个pppoe for win2000的源程序来研究

我在这上面找了一个遍也没找到源程序，当真有的话，能给一个连接吗？ [/quote]

是啊，是啊！！！

 :D :D :D

我也要！谢谢
nicdriver@sina.com

也给我发一份，好吗？
xujianxjxujian@163.com
谢谢！

也给我发一份吧
chenxu_sky@163.com
谢谢

拜托了，也给我一份！万分感谢！！！

[quote]给我一份！！！
syuanyy@371.net

我再上传一次试试看。
 [/quote]
还是下不了，你发给我一份吧，然后我把它放到“文件交流区”去，就可供大家共享了。Email : BlueLight@371.net

也给我来一份，谢谢 :P

要要要要。
wbokey@hotmail.com

发信人: Immortal1015 (后处理~列拷贝专家), 信区: DriverDev      
标  题: 驱动开发网：一种PPPoE驱动程序设计方案
发信站: BBS 水木清华站 (Sun Sep  9 22:58:16 2001)

---------------------
标题:一种PPPoE驱动程序设计方案
出处:驱动开发网
---------------------
详细图表请见附件文档,感谢fang提交。
PPPoE驱动程序设计方案
1.1 概述
i. 背景
随着宽带技术的突破，Internet将急剧地改变我们面对的数字化环境。可以高速地提供
流媒体服务；可以方便地实现VPN服务；推进企业电子商务的实施；也给ICP提供新的机
会，以彻底解决宽带Internet赢利模式短缺的问题；同时促进了Internet数据中心(IDC
)向各行各业扩展。
宽带接入技术目前主要集中在以太网、广电网、ADSL技术、无线接入技术上。
ADSL全称非对称数字用户线路技术，是DSL的一种非对称版本，它利用数字编码技术从现
有铜质电话线上获取最大数据传输容量，同时又不干扰在同一条线上进行的常规话音服
务。
PPPoE 技术简化了用户接入设备的复杂程度。目前广泛使用的两种协议：Ethernet 和P
PP 。前者是局域网中的标准协议，后者则是用户拨号接入Internet的标准方式。而PPP
oE正是利用了这两种广泛使用的技术，加以改进形成的。用户还是使用他熟悉的硬件以
及类似的软件进Internet的接入动作。从ISP的角度来看，PPPoE也没有对其现存的网络
结构进行任何变更。
目前在Windows系统上，还没有实现对PPPoE协议的支持。第三方开发商提供的PPPoE客户
端软件软件知名的有Enternet300，WinPoET，RASPPPoE等。其中RASPPPoE允许个人用户
免费下载使用。
ii. 方案选择
我们要自己实现一个驱动程序 来支持PPPoE协议，有必要说明，这里仅仅能够给出实现
的方案和一些细节解释，至于编码实现本文就无能为力了。因为我们将要提到的这个驱
动程序目前仅仅是纸上谈兵，并没有能够使它真正运行起来。
首先，有必要了解清楚实现方案。PPPoE的应用方式决定了驱动程序工作模型，所以先来
看一下ADSL Modem接入图。
 （From Internet）
上面这幅图表明了PPPoE工作连接方式。或者我们看下面这幅图，可能更容易理解。
可以看出，在PC上首先必须安装一块以太网卡，ADSL Modem通过10Base-T双绞线和网卡
连接。PPPoE驱动程序将通过控制以太网卡提供网络服务。
在Windows系统上，操作系统提供网络服务的系统模块称之为NDIS ，PPPoE驱动程序实现
模型大多是利用NDIS中间层驱动程序来实现。NDIS驱动程序模型如下。
图中可以看出，我们不需要写操纵以太网卡的驱动程序，只需要在网卡驱动程序上面增
加一个中间层驱动程序，来做PPPoE协议转换层。
Enternet300，WinPoET，RASPPPoE都是基于这种方法实现。不过实现细节又有所不同不
同。下面介绍一下。
Enternet300可以说是实现的最好一个PPPoE协议驱动程序。我们知道PPPoE协议中文意思
是以太网上的点对点协议，本质是PPP协议内容用以太网帧封装，通过ADSL Modem传递的
一种技术。之所以说Enternet300实现比较好，就是因为它部分实现了PPP协议和PPPoE协
议，不再用Microsoft的拨号网络系统组件的支持。绕过了拨号网络中NdisWan的转换，
可以实现较好的控制，节省了系统资源。
WinPoET，RASPPPoE则利用了拨号网络提供的PPP协议支持。安装这种驱动程序之前，要
求用户首先必须安装拨号网络组件。这种实现的好处是显而易见的，避免了实现PPP协议
的麻烦。实际上，PPPoE协议本身并不比PPP协议复杂。
因此，我们的方案也将参照RASPPPoE的方式来做。利用NDIS中间层驱动程序机制，实现
一个具有Wan miniport上沿接口、Protocol下沿接口的中间层驱动程序，使其工作在Nd
isWan和以太网卡驱动程序之间，完成PPPoE协议转换工作；利用WAN miniport提供的上
沿函数支持拨号网络的拨号服务，完成虚拟拨号；
1.2 编写程序的前提和准备
由于编写Windows驱动程序是一项比较艰巨的任务，尝试编写之前，很有必要首先弄清楚
要胜任这样的任务需要那些准备工作。
Ø 基础知识
ü 熟练掌握C语言；
ü 熟习Win32 API，有过Windows下编程经历；
ü 熟练掌握Windows 内存管理机制，进程线程执行、调度、同步知识。
Ø 需要阅读的内容
ü Windows 2000 DDK  有关网络驱动程序部分；
ü PPPoE协议；
ü PPP相关协议 ；
Ø 编译调试环境
ü Vc++6.0或更高版本；
ü Windows 2000 DDK;
ü 选用第三方调试工具SoftIce或DDK调试工具中WinDbg，Kd，NTSD之一；
下面将会逐步介绍以上提到的各部分内容。
1.3 程序编制的主要内容
iii. 建议使用passthru的架构代码
实现这样一个NDIS中间层驱动程序，最好能具有一定的工作基础，让我们不至于所有的
东西都要从头开始。DDK中附带的示范代码passthru是一个中间层过滤型的驱动程序。框
架结构非常清晰规范，正适合我们这样的初学者模仿练习。恰巧我们的驱动程序也是一
个中间层驱动程序，结构上有很大的共性。尽管在很多方面需要修改，但至少代码结构
和“即插即用”部分是完全不用修改的。因此建议就在passthru源代码基础上修改增加
，完成我们的驱动程序编写。为了书写方便，我们将要编写的驱动程序就叫做TestPPPo
E。
iv. R/S 机制
接收/发送网络包，是整个驱动程序的主要工作内容，TestPPPoE就将在这个过程中完成
PPPoE协议转换过程。出乎意料的是，在NDIS体系中，接收/发送网络包并不是一成不变
的Send/Receive两个函数。为了详尽地讲述收发机制，我们得首先弄清楚中间层驱动程
序工作原理。下一章将详尽介绍。
v. 增加WAN 支持
Windows NDIS体系中包括对广域网的支持，NDIS中定义了三种网络驱动程序工作环境，
无连接网络，有向连接网络，广域网环境。其中，广域网驱动程序环境支持前两种网络
设备。有关NDIS体系的详细描述，下一章将有介绍。
vi. 增加TAPI 支持
WAN类型驱动程序使用PPP协议来进行网络通讯，最典型的应用是通过固定电话拨号上网
，TAPI是微软定义的电话接口API，借此来屏蔽掉各种调制解调器的字符命令集的差异，
实现硬件无关性。TestPPPoE利用了拨号网络，必然被要求支持TAPI，TestPPPoE也将借
此实现虚拟拨号过程。
vii. 增加PPPOE支持
主要是根据PPPoE协议，实现对PPPoE协议的支持。
viii. 增加HDLC-Like Frame 支持
HDLC-Like Frame是一种封装方法，PPP帧在数据线上发送之前要采用这种编码方法封装
。由于NdisWan传递给TestPPPoE的帧是用HDLC简单封装过的帧，TestPPPoE将被迫解开封
装，重新组装成PPPoE帧格式，PPPoE帧格式不需要HDLC-Like Frame；从下层网卡接收到
PPPoE帧之后，TestPPPoE又必须把PPPoE转换成简单封装过的PPP帧，传给NdisWan。
1.4 方案中技术要点简介
ix. NDIS体系结构
尽管以上已经介绍了一些内容，不过估计在还没有仔细阅读Windows DDK之前，对TestP
PPoE工作机制可能还是不甚明了。这一节将从NDIS的体系上试图讲清楚中间层驱动程序
工作原理。读者也可以开始阅读DDK文档了。需要说明的是，本文档并不能达到使读者只
需阅读本文档即可完成编写程序的目的。以下的介绍致力于对某些比较关键的地方作一
些解释。
NDIS体系是遵循OSI七层模型的，不过具体划分层次的时候，并没有一一对应的层次结构
。NDIS定义了物理硬件，小端口驱动，协议驱动，传输驱动接口四个层次。小端口驱动
程序负责驱动物理硬件，屏蔽物理硬件的差异，提供标准的MiniportXXX上沿接口；协议
驱动程序一般用作传输协议栈的底层驱动，它提供ProtocolXXX下沿接口，上沿接口是私
有的，被传输协议栈调用；传输驱动接口程序定义了核心模式的网络接口；有关这部分
内容的详尽解释，请参看DDK “Network Architecture for Kernel-Mode Drivers”一
节。
x. 中间层驱动程序工作机制
中间层驱动程序是比较特殊的一种形式。我们来看看它的结构图。
它的上沿是MiniportXXX上沿接口，下沿却是ProtocolXXX下沿接口。这样的效果就是，
对下层的小端口驱动程序来说，它是一个协议驱动程序；对上层的协议驱动程序来说，
它是一个小端口驱动程序。
DDK说明这种驱动程序的一般典型用途有三种：
Ø 转换两种不同的网络介质，比如TestPPPoE要做的，在PPPoE帧和PPP帧之间做
转换；
Ø 包过滤，Passthru即是一个透明的过滤驱动程序。值得注意的是，现在Windo
ws上单机防火墙就是利用这种机制实现。
Ø 负载平衡，在又多个物理网卡时，对上层仅提供一个可绑定的虚拟网卡，可以
根据工作状况，自动选择负载量轻网卡发送网络包。Passthru即实现了LBFO
xi. 网络驱动程序工作环境
网络驱动程序工作环境这个词不好解释，原来的词是Network Driver Environments，应
当理解成各种类型网络驱动程序工作环境。也就是说，网络设备的不同，导致各驱动程
序工作环境不同。
NDIS中定义了三种网络驱动程序工作环境，无连接网络，有向连接网络，广域网络环境
。其中，广域网驱动程序环境支持前两种网络设备。
无连接网络，比如以太网，令牌环网络，就是无连接类型的；NDIS中把无连接网络环境
作为一种参考标准。印象中NDIS_PACKET结构中网络载体一般用802.3帧格式。
有向网络环境，比如ATM。
广域网络环境，它定义了点到点连接，使用底层设备可以是任何无连接网络设备或者有
向网络设备或其他专有设备。DDK实现了远程访问服务。RAS体系图如下：
Ø RAS提供了拨号，建立连接的功能；
Ø NdisWan是一个中间层驱动程序，做PPP协议连接的封装，压缩，加密，它在N
DIS_PACKET和NDIS_WAN_PACKET间做相互转换，也就是说，它相互转换以太网帧和PPP帧
。
Ø WAN 小端口驱动程序，工作在NdisWan的下层，和普通小端口驱动程序主要不
同，是它接收的数据结构是NDIS_WAN_PACKET，而不是NDIS_PACKET。面对的是WAN的环境
，而且要支持TAPI，实现拨号过程。TestPPPoE也是一个Wan miniport。
xii. R/S机制
到目前为止，终于算是走到正题，现在假设你已经对NDIS体系，对TestPPPoE的工作机制
已经有所了解，对具体如何着手编写TestPPPoE需要做那些准备工作已经做好，并且已经
明白我们将要如何修改Passthru以达到我们的目标。如果你对一些名词还是很陌生，建
议最好再读读相应的资料。我们在本文末尾提供了可以参考的各种资源。
我想我们程序员在已经有了一个可以工作的中间层驱动程序代码之后，最想做的就是在
源代码中找到如何发送网络包，和如何接收网络包的函数。以为只要修改了这部分就基
本上万事大吉了。
非常不幸的是，NDIS的收发机制并没有如此简单，而且收发机制尽管重要，但其他方面
我们将要增加的源代码也不会少。
小端口驱动程序分Serialized miniport和Deserialized miniport两种，它的意思是说
发送接收包是串行的还是非串行的。并不是同步异步的意思。根本的看法是，Serializ
ed miniport在没有发送资源或发送队列已满的情况下，可以拒绝发送，NDIS将会在该驱
动程序有发送能力，再次要求其发送；而Deserialized miniport无论是否有能力发送，
都要接收该网络包，在其内部存储排队，等待发送。不能拒绝发送请求。这就要求其具
有内部缓冲队列，自己管理该队列。这种驱动程序通常使用性能较高。所有的WAN mini
port都要求是Deserialized miniport。大多数的以太网卡的驱动程序也是Deserialize
d miniport。
为了提供性能，NDIS提供了单包发送和多包发送选择，而且声明，如果存在注册了Mini
portSendPackers()函数，将总是使用MiniportSendPackers，而不用MiniportSend()。
TestPPPoE位于NdisWan下层，每次只接收一个NDIS_WAN_PACKET结构中仅包含一个PPP帧
，所以我们不必考虑多包发送机制。而且TestPPPoE是作为NIC硬件驱动的协议来运行，
以太网是属于无连接类型，所以这里仅介绍无连接类型单包发送机制。
Ø 单包发送机制（以下部分译自Windows 2000 DDK,Network Driver,Design Gu
ide,Part2:Miniport NIC Driver, 4.4.2 Single-Packet Sends from Connectionless
 Miniports）：
单包发送的函数是：
NDIS_STATUS
  MiniportSend(
    IN NDIS_HANDLE  MiniportAdapterContext,
    IN PNDIS_PACKET  Packet,
    IN UINT  Flags
    );
如果小端口驱动程序能够立即完成发送操作，它返回NDIS_STATUS_SUCCESS，如果因为某
种原因失败，它返回NDIS_STATUS_FAILUER，这时它将放弃对网络包的控制权。这种情况
下不应该设置带外数据块中的status成员变量。
 （同步完成的情况）
如果小端口驱动程序不立即完成发送操作，它返回NDIS_STATUS_PENDING，在这种情况下
，直至发送完毕之前它保留对网络包的控制权，调用者不能释放相应的网络包资源。发
送完毕后，该驱动必须调用NdisMSendComplete，传回已经发送完毕的网络包的指针，不
再拥有控制权，调用者可以释放相应的资源，以便于再次使用。
 串行驱动程序如何处理资源问题：
假如一个serialized miniport遇到资源短缺的情况，它返回NDIS_STATUS_RESOURCES，
这种情况下，NDIS缓冲这个包，并且当serialized miniport调用NdisMSendResourcesA
vailable或者NdisMSendComplete来通知NDIS它现在可以发送时，NDIS重新发送这个被缓
冲的网络包。
非串行驱动程序如何处理资源问题：
假如一个deserialized miniport遇到资源短缺的情况，它必须在内部缓冲这个包，并且
返回NDIS_STATUS_PENDING，它不允许返回NDIS_STATUS_RESOURCES，它自己负责处理内
部缓冲直至这个包能够发送为止。
在TestPPPoE看来，以上图中的miniport指的是位于TestPPPoE下层的NIC驱动程序，Tes
tPPPoE只需调用NdisSend，由NDIS来调用MiniportSend。在TestPPPoE中，只需注意两点
即可，如果NdisSend返回NDIS_STATUS_SUCCESS/NDIS_STATUS_FAILURE，那么直接处理即
可。如果NdisSend返回NDIS_STATUS_PENDING，说明操作正在进行，以后该miniport一定
会调用NdisMSendComplete，从而触发ProtocolSendComplete，TestPPPoE必须在此处处
理这种异步情况。释放相应的资源。通知NdisWan发送完成。
由于TestPPPoE的下一层是NIC的miniport，它通知NDIS有数据到达的形式有多种可能。
每一种情况TestPPPoE都不应忽略。（以下出自Windows 2000 DDK,Network Driver,Des
ign Guide,Part2:Miniport NIC Driver, 4.6.1 Multipacket Receives from Connect
ionless and Connection-Oriented Miniports ，4.6.2 Single-Packet Receives fro
m Connectionless Miniports）。
多包接收：
小端口驱动程序准备好一组包描述符，用到来的数据填充好内容，即可调用NdisMIndic
ateReceivePacket。所有的包描述符都应该包含全部数据。
小端口驱动程序可以设置每一个包描述符的状态，状态在每一个描述符的带外数据块中
设置。小端口驱动程序可以把状态设置成NDIS_STATUS_SUCCESS，就可以允许协议驱动程
序保留这个包描述符使用权，协议使用完毕以后，再用MiniportReturnPacket函数返回
包描述符。如果小端口驱动程序资源紧张，希望上层协议立即拷贝数据内容，以便尽快
返回包描述符，那么就把状态设置成NDIS_STATUS_RESOURCES。
单包接收：
一个无连接的小端口驱动程序调用NdisMXxxIndicateReceive ，传递了部分数据给上层
协议驱动程序，如果协议驱动程序对包头部分析，认为有必要接收整个数据包，就必须
调用NdisTransferData，要求下层把剩余数据送过来。这里有分为两种情况：
 第一种，下层的MiniportTransferData同步完成传送，传送完毕，必须调用NdisMXxxI
ndicateReceiveComplete。以便通知NDIS。
 第二种，下层的miniport是慢速设备，数据到来的时间段较长，这种情况下，minipor
t很可能选择MiniportTransferData用异步方式，首先返回NDIS_STATUS_PENDING，数据
全部获得后调用NdisMTransferDataComplete，通知传送完成，然后必须调用NdisMXxxI
ndicateReceiveComplete。以便通知NDIS。
调用机制：（以下出自Windows 2000 DDK,Network Driver,Design Guide,Part 3:Inte
rmediate NDIS Drivers and TDI Drivers,1.5.1 Receiving Data in an Intermediat
e Driver with a Connectionless Lower Edge）
当下层的miniport有多个数据包到达或者有带外数据的时候，它使用多包接收函数Ndis
MIndicateReceivePacket来向NDIS指明。一般来说，NDIS会多次调用TestPPPoE的Proto
colReceivePacket函数，每次传送一个完整的数据包。带外数据的情况我们就不讲了，
PPPoE不包括带外数据的内容。这时TestPPPoE就获得了对数据包的只读控制权。使用完
毕之后，要求TestPPPoE必须使用NdisReturn返回控制权。
有一种例外情况，就是NDIS在这种情况下有可能不调用TestPPPoE的ProtocolReceivePa
cket函数，而调用ProtocolReceive函数。是这样的，这时候底层的miniport有可能资源
不足，为了能够让上层驱动程序迅速放弃对数据包控制权，它在每一个数据包的带外数
据块中设置status属性为NDIS_STATUS_SOURCE，这样就迫使NDIS转而调用ProtocolRece
ive函数，强迫TestPPPoE拷贝每一个数据包。
当下层的miniport调用NdisMXxxIndicate的时候，NDIS总是调用TestPPPoE的ProtocolR
eceive函数。由于这种情况一般都是部分数据到达，所以TestPPPoE要想取得完整的数据
包，就必须调用NdisTransferData。从以上的介绍可以看到TestPPPoE的ProtocolRecei
ve函数有两个路径。一个是由NdisMIndicateReceivePacket触发，一个是由NdisMXxxIn
dicate触发。程序必须区分正两种情况。
如果一个是由NdisMXxxIndicate触发，那么ProtocolReceive函数接收到的数据不会大于
OID_GEN_CURRENT_LOOKAHEAD；如果是由NdisMXxxIndicate触发，那么ProtocolReceive
函数接收到的数据总是等于全部数据包的大小，也就不必再用NdisTransferData来要求
传输余下的数据了。（如果读者对这些函数的功能不明，请查阅ddk文档）。
ProtocolReceive函数必须尽快返回控制，如果ProtocolReceive函数对头部数据检查后
，认为不是自己感兴趣的数据包，就返回NDIS_STATUS_NOT_ACCEPTED。
ProtocolReceive函数不应立即处理接收到的数据，这会影响系统性能。TestPPPoE最好
在ProtocolReceiveComplete函数对接收的数据作后续处理。ProtocolReceiveComplete
函数随后将被调用。TestPPPoE要注意使接收的数据对ProtocolReceiveComplete函数可
见、有效。
xiii. NDIS_PACKET介绍
NDIS_PACKET是整个NDIS体系的核心数据机构，所有流入流出的网络数据报文在NDIS中都
将以NDIS_PACKET来表示。为了提供平台无关性，NDIS中不少的函数都是NDIS_PACKET操
作函数。我们先来看看NDIS_PACKET的数据结构。
需要注意的是，NDIS_PACKET结构在Windows98和Windows2000上实现有点不同，为了实现
源代码的平台无关性，一定要避免直接操纵NDIS_PACKET结构，而是要使用NDIS提供的操
作函数来操作。
尽管如此，我们还有有必要弄清楚NDIS_PACKET结构的内容，这对我们理解如何正确使用
操作函数有利。
typedef struct _NDIS_PACKET {
    NDIS_PACKET_PRIVATE  Private;
    union {
        struct {
             UCHAR       MiniportReserved[2*sizeof(PVOID)];
             UCHAR       WrapperReserved[2*sizeof(PVOID)];
        };
        struct {
             UCHAR       MiniportReservedEx[3*sizeof(PVOID)];
             UCHAR       WrapperReservedEx[sizeof(PVOID)];
        };
        struct {
             UCHAR       MacReserved[4*sizeof(PVOID)];
        };
    };
    ULONG_PTR            Reserved[2];
    UCHAR                ProtocolReserved[1];
} NDIS_PACKET, *PNDIS_PACKET, **PPNDIS_PACKET;
NDIS_PACKET结构的其他几个成员请读者阅读DDK文档，有具体的使用说明。而DDK不提倡
了解NDIS_PACKET_PRIVATE  Private成员的细节，所以NDIS_PACKET_PRIVATE在DDK文档
中没有说明。在ndis.h头文件中我们可以看到NDIS_PACKET_PRIVATE结构在Windows 200
0的定义：
typedef struct _NDIS_PACKET_PRIVATE
{
 UINT    PhysicalCount; // number of physical pages in packet.
 UINT    TotalLength; // Total amount of data in the packet.
 PNDIS_BUFFER  Head;   // first buffer in the chain
 PNDIS_BUFFER  Tail;   // last buffer in the chain
 // if Head is NULL the chain is empty; Tail doesn\'t have to be NULL also
 PNDIS_PACKET_POOL Pool;   // so we know where to free it back to
 UINT    Count;
 ULONG    Flags;
 BOOLEAN    ValidCounts;
 UCHAR    NdisPacketFlags; // See fPACKET_xxx bits below
 USHORT    NdisPacketOobOffset;
} NDIS_PACKET_PRIVATE, * PNDIS_PACKET_PRIVATE;
我们所关心的真正的数据报文就在多个串联起来的NDIS_BUFFER中，需要说明的是，在W
indows 2000/XP中NDIS_BUFFER其实是MDL ，我们看下面的定义：
typedef struct _MDL {
 struct _MDL *Next;
 CSHORT Size;
 CSHORT MdlFlags;
 struct _EPROCESS *Process;
 PVOID MappedSystemVa;
 PVOID StartVa;
 ULONG ByteCount;
 ULONG ByteOffset;
} MDL;
typedef MDL NDIS_BUFFER;
而在Windows9x/ME中，PNDIS_BUFFER定义如下：
typedef struct _NDIS_BUFFER {
 struct _NDIS_BUFFER *Next;
 PVOID VirtualAddress;
 PNDIS_BUFFER_POOL Pool;
 UINT Length;
 UINT Signature; // ‘NBUF’
} NDIS_BUFFER;
因此，TestPPPoE在任何时候都最好不要直接操纵NDIS_BUFFER结构。而是使用NdisQuer
yBuffer函数获得该缓冲区的虚拟地址和数据长度来操作数据报文。
以下部分出自http://pcausa.com的讨论组。
当我们发出C:> ping 192.168.1.64这样的命令的时候，在网络上实际传输的数据是这样
的：
000000: 00 A0 CC 63 08 1B 00 40 : 95 49 03 5F 08 00 45 00 ...c...@.I._..E.
000010: 00 3C 82 47 00 00 20 01 : 94 C9 C0 A8 01 20 C0 A8 .<.G.. ...... ..
000020: 01 40 08 00 48 5C 01 00 : 04 00 61 62 63 64 65 66 .@..H\\....abcdef
000030: 67 68 69 6A 6B 6C 6D 6E : 6F 70 71 72 73 74 75 76 ghijklmnopqrstuv
000040: 77 61 62 63 64 65 66 67 : 68 69                   wabcdefghi......
网络报文在NDIS_PACKET中的可能的位置如下图所示，所有的网络报文都在一块NDIS_BU
FFER中，NDIS_PACKET仅包含一个NDIS_BUFFER。
如果情况复杂一些，那么可能的情况就是这样的。ICMP数据报被分在两块NDIS_BUFFER中
。在内存中是不连续的内存块。
尽管以上的图形想地描述了NDIS_PACKET的数据结构。但在使用的时候，我们不应该直接
操作NDIS_BUFFER，应把它看成不透明的一个实体。下面提供一些函数来辅助访问这个数
据块内容。
NdisQueryPacket   返回包描述符中的第一个缓冲区。
NdisQueryBuffer   返回缓冲区中的虚拟地址和数据长度。
NdisGetNextBuffer  返回下一个缓冲区。
NdisQueryBufferSafe同NdisQueryBuffer，仅用于NDIS5.1以上版本。
（简单的情况：所有的网络报文都在一块NDIS_BUFFER中）
（复杂一点的情况：ICMP数据报被分在两块NDIS_BUFFER中）
使用NDIS_PACKET结构中保留字段的基本规则：
&Oslash; 假如一个协议驱动程序分配NDIS_PACKET描述符：
l 协议驱动程序可以使用ProtocolReserve字段；
l 下一层小端口驱动程序可以使用MiniportReserve字段；
&Oslash; 假如一个小端口驱动程序分配NDIS_PACKET描述符：
l 小端口驱动程序可以使用MiniportReserve字段；
l 上一层的协议驱动程序可以使用ProtocolReserve字段；
中间层驱动程序使用规则：
&Oslash; 针对将被发送的NDIS_PACKET描述符：
l 描述符从上一层协议进入中间层驱动程序，把中间层驱动程序看作小端口驱动程序；

l 描述符从中间层驱动进入下一层小端口驱动，把中间层驱动程序看作协议驱动程序；

&Oslash; 针对将被接收的NDIS_PACKET描述符：
l 描述符从下一层小端口进入中间层驱动，把中间层驱动程序看作协议驱动程序；
l 描述符从中间层驱动传递给上一层协议驱动，把中间层驱动程序看作小端口驱动程序
；
然后再参照基本规则来使用保留字段。
xiv. WAN支持
xv. TAPI支持
xvi. PPPOE协议概述
xvii. HDLC封装
xviii. 安装（inf 文件/ notify object）
xix. 调试
1.5 结束语

--

※ 来源:?BBS 水木清华站 smth.org?[FROM: 166.111.37.73]

在专栏文章中都不能下，看不到图。麻烦发我一份：
    t154058238@hotmail.com
谢谢！


[编辑 -  1/21/03 by  lutty]

现在老板要我做PPPOE，我连概念都没有，恳请您的帮助。
希望您能将这个方案发到我的邮箱，让我学习学习。谢谢了！
peakame@163.com
thanks again！ :(