NET_BUFFER 用来描述一个数据包
NET_BUFFER_LIST 用来描述共享元数据(OOB带外数据)的多个数据包
NET_BUFFER_LIST 可以是一个链表,即多个NBL连接在一起
NET_BUFFER 由多个MDL连接在一起构成,为什么这样设计的,通常构造一个数据包的方法是自下而上,就是先构造包体,再构造包头,包头,包头……
由于是这样一个自下而上的过程,就有了 Retreat Advance 两个动作,详解请参考
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/net-buffer-list-structure
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/net-buffer-structure
WFP callout每种回调场景的offset都不一样,参考资料
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/data-offset-positions
关于收发包NBL和NB的相关资料
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/sending-ethernet-frames
关于WFP callout包的资料
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/packet-indication-format
简单总结下来基本就是
1.WFP callout 除了STREAM path和FORWARD path,只会在回调中给一个NBL,而不是NBL chain。
2.如果NBL中有多个NB,那么这些NB具有完全相同的2、3层地址。
不得不说自从微软收购了github并将其应用在自己的msdn之后,微软的文档友好多了。而且微软还有专门的职位叫"内容开发者",就专职写文档的。以前想写个WFP贼费劲,啥啥没有全靠猜,现在每个场景每个API文档非常清晰。
另外关于MDL是否可以修改的问题,搜索了一些内容
https://community.osr.com/discussion/284088/netbufferlist-chain-using-same-mdl
OSR中的以为NDIS架构师大神说在内核里都是假设MDL是可写的,完全无视NBL中只读标志。
然而第二个msdn论坛的有人反馈http.sys在作出错误回应时会使用只读内存。
我之前给别人做NDIS驱动时就遇到这个问题,当时是在服务器上部署NDISFilter总是过一段时间莫名其妙出现写Readonly故障,当时是Rebuild解决的,今天终于明白了,原来是这么回事。