eth头是谁加的？包包屁股上的0是谁加的？

我在NDIS IM驱动中得到的packet已经是eth包了，问题是这个头是谁加上的呢？
是ndis framework加的还是其他什么神秘的东西加上去的？
那位老大给个详细一点的解释，就说ETH包好了，加头/去头和分帧/组装都在哪里做的啊？一脑子浆糊！
令外我在测试中发现有时我的包包屁股后会被加上几个0，看着挺像padding的，可是为什么呢，我不想要啊。代码出什么错误会导致这样啊？跪求答案！

关于第二个问题，已经找到答案了：
包尾的0是因为包太小，eth包最小46bytes，所以加了写padding。
（谁在丢西红柿！问题蠢不是我的错！）
第一个问题还没搞定，大家帮忙啊

我觉得是TCP/IP协议栈添上去的吧，NDIS库只是对包的管理

可是eth头是LLC这一层的东西，按说不应该归tcpip.sys管啊。
我再详细解释一下我的问题，希望这次能说明白

下面这个示意图没有考虑windows协议栈的细节，只考虑NDIS相关：

    tcp/ip
-------------------
  NDIS Framework
-------------------
miniport interface
   IM Driver
protocol interface
-------------------
  NDIS Framework
-------------------
  Miniport Driver

IM Driver从prtocol interface获得的包带有eth头还可以理解，因为
IM Driveer对于下层驱动看来应该在LLC层以上。
可是对于从miniport interface获得的包来说，已经带eth头就有点怪
了，因为tcp/ip层不知道下层协议是什么，按说不应该加LLC层的头啊，
所以觉得应该是NDIS或其他什么机制加了这个头。
感觉上packet应该先过NDIS,然后是IM Driver，最后才过minport。
所以觉得NDIS有机会加这个头，但实际内幕到底如何呢？

还是疑惑啊！

windows 的TCP/IP协议栈实现了几层啊，如果只实现了网络层以上，那么ETH头就不应该是协议栈添的。

我觉得应该是在miniport driver及以下的驱动中完成添加的

应该是tcp ip加的吧。
用nidssend直接发包时不就是自己写ether头吗，
tcpip最终也是 调用nidssend来发包，
所以应该是由tcpip来写ehter头。

我想MiniPort 驱动添加的