为什么我的Passthru拦不到包？

在ptReceive里面NdisGetReceivedPacket返回总是NULL，为什么啊？？？？

It\'s possbile. The underlying NIC may indicate packets up by calling NdisMEthIndicateReceive, in this case you need to check the look ahead buffer and call NdisMEthIndicateReceive to pass this frame to upper-layer protocol.

本坛以前有帖子详细讨论过这个问题，你最好先搜索一下。
简单的说就是一个miniport传上来的包没有oob数据，NdisGetReceivedPacket返回的就是空。

passthru的例子里面不是有怎处理的么？

还是好好看看passthru的例子吧，兄弟！！！！！

还是好好看看passthru的例子吧，兄弟！！！！！

看你个头看，要是光看passthru就能解决这个问题我佩服你，blue斑竹以前都没解决。

现在我看了huyu以前发的帖子，问题基本解决。

顺便说一下，你不能解决问题别在这里灌水讲风凉话，一边蹲着去！

解决了，就说出来吧！！！谢谢
要不然，还不是会有人问这个问题

我把以前huyu版主的帖子作为附件发上来把

[quote]还是好好看看passthru的例子吧，兄弟！！！！！

看你个头看，要是光看passthru就能解决这个问题我佩服你，blue斑竹以前都没解决。

现在我看了huyu以前发的帖子，问题基本解决。

顺便说一下，你不能解决问题别在这里灌水讲风凉话，一边蹲着去！ [/quote]

哥们，你这样说话很不好吧。如果你passthru真的看明白了，流程也不会不清楚了

[quote][quote]还是好好看看passthru的例子吧，兄弟！！！！！

看你个头看，要是光看passthru就能解决这个问题我佩服你，blue斑竹以前都没解决。

现在我看了huyu以前发的帖子，问题基本解决。

顺便说一下，你不能解决问题别在这里灌水讲风凉话，一边蹲着去！ [/quote]

哥们，你这样说话很不好吧。如果你passthru真的看明白了，流程也不会不清楚了 [/quote]

我问的那个问题是和流程没有关系的，简单的说
老网卡不会去调用PtReceivePacket，而且不封包，直接传数据
这个请问Passthru里面哪里讲了？你光看Passthru例子能想到
是因为网卡的原因？

[quote][quote][quote]还是好好看看passthru的例子吧，兄弟！！！！！

看你个头看，要是光看passthru就能解决这个问题我佩服你，blue斑竹以前都没解决。

现在我看了huyu以前发的帖子，问题基本解决。

顺便说一下，你不能解决问题别在这里灌水讲风凉话，一边蹲着去！ [/quote]

哥们，你这样说话很不好吧。如果你passthru真的看明白了，流程也不会不清楚了 [/quote]

我问的那个问题是和流程没有关系的，简单的说
老网卡不会去调用PtReceivePacket，而且不封包，直接传数据
这个请问Passthru里面哪里讲了？你光看Passthru例子能想到
是因为网卡的原因？ [/quote]

ptreceive是什么时候用的、是干吗用的？？你既然都看懂了怎么还会问这么愚蠢的问题。

你这样说话还想让别人回答你的问题么？

你自己慢慢看吧。

ProtocolReceive
The ProtocolReceive function is a required driver function in NDIS protocols that bind themselves to connectionless NIC drivers. ProtocolReceive determines whether a received network packet is of interest to the protocol’s client(s) and, if so, copies the indicated data and, possibly, calls NdisTransferData to retrieve the rest of the indicated packet.

NDIS_STATUS
  ProtocolReceive(
    IN NDIS_HANDLE  ProtocolBindingContext,
    IN NDIS_HANDLE  MacReceiveContext,
    IN PVOID  HeaderBuffer,
    IN UINT  HeaderBufferSize,
    IN PVOID  LookAheadBuffer,
    IN UINT  LookaheadBufferSize,
    IN UINT  PacketSize
    );
Parameters
ProtocolBindingContext
Specifies the handle to a protocol-allocated context area in which the protocol driver maintains per-binding run-time state. The driver supplied this handle when it called NdisOpenAdapter.
MacReceiveContext
Specifies a context handle that the underlying NIC driver associates with the packet received from the network. This handle is opaque to the protocol, reserved for use by the underlying driver that made the indication, and a required parameter to NdisTransferData.
HeaderBuffer
Pointer to the base virtual address of a range containing the buffered packet header. The address is valid only within the current call to ProtocolReceive.
HeaderBufferSize
Specifies the number of bytes in the packet header.
LookAheadBuffer
Pointer to the base virtual address of a range that contains LookaheadBufferSize bytes of buffered network packet data. This address is valid only within the current call to ProtocolReceive.
LookaheadBufferSize
Specifies the number of bytes of network packet data in the lookahead buffer.
The indicating driver ensures this number is at least as large as the size it returned for the protocol’s preceding call to NdisRequest with OID_GEN_CURRENT_LOOKAHEAD or the size of the packet, whichever is less.

If PacketSize is less than or equal to the given LookaheadBufferSize, the lookahead buffer contains the entire packet.

PacketSize
Specifies the size, in bytes, of the network packet data. The length of the packet does not include the length of the header.
ProtocolReceive determines whether the protocol must call NdisTransferData by comparing this parameter to the given LookaheadBufferSize.

Return Value
ProtocolReceive can return either of the following:

NDIS_STATUS_NOT_ACCEPTED
The protocol has no use for the indicated packet, that is, it has no current clients interested in the indicated network data.
Returning this status quickly for rejected packets yields higher performance for the protocol and the highest possible network I/O throughput for the system as a whole.

NDIS_STATUS_SUCCESS
ProtocolReceive has processed the header information and accepted the packet, that is, it has copied the indicated network data from the header and lookahead buffers and, possibly, called NdisTransferData to retrieve the remaining data if less than a full network packet was indicated.
Headers
Declared in Ndis.h. Include Ndis.h.

Comments
NDIS provides equal packet access for any number of protocol drivers bound above an underlying connectionless miniport driver. NDIS can use the status that ProtocolReceive returns to optimize the order in which bound protocols receive indications for subsequent packets.

When a miniport driver calls a filter-specific NdisM..IndicateReceive function, NDIS calls the ProtocolReceive functions of bound protocols. A call to an NdisM..IndicateReceive function indicates that a network packet, or some initial lookahead portion of it, is available for inspection by bound protocols. Each ProtocolReceive function, in turn, inspects the packet header and data, optionally copies as much of the header and/or data as is made available, and calls NdisTransferData to instruct the NIC driver to copy any remaining data into a protocol-supplied buffer chained to a protocol-allocated packet descriptor if the protocol accepts the packet. ProtocolReceive can call NdisTransferData only once per receive indication.

Before a serialized miniport driver calls NdisMIndicateReceivePacket with a packet array, it can set the Status member of an out-of-band block associated with a packet descriptor in the array to NDIS_STATUS_RESOURCES. This also causes NDIS to call the ProtocolReceive functions of bound protocols with the network packet header and data specified by that packet descriptor and, separately, with the received network packets specified in all subsequent descriptors in the indicated packet array. Each ProtocolReceive function, in turn, inspects the given network packet header and data and each optionally copies the indicated network packet data.

If the underlying miniport driver supplies out-of-band information with the receives it indicates, ProtocolReceive can call NdisGetReceivedPacket or NDIS_GET_ORIGINAL_PACKET to retrieve the out-of-band information for each such packet. Because such an underlying miniport driver always indicates full-packet receives, ProtocolReceive will never call NdisTransferData for a packet indicated with NdisMIndicateReceivePacket.

NDIS calls ProtocolReceive functions sequentially as calls to NdisM..IndicateReceive or NdisMIndicateReceivePacket occur, but it can indicate a packet to bound protocols using separate calls. However, every protocol must be able to handle out-of-order received packets since neither NDIS nor the underlying miniport driver has any control over the network over which packets are transmitted.

A driver writer should minimize the amount of time spent in the ProtocolReceive function so that the protocol does not lose additional incoming packets, particularly from underlying drivers that call the filter-specific NdisM...IndicateReceive functions. ProtocolReceive must either reject an incoming packet or recognize the packet as of interest to its client(s) quickly. If it accepts the packet, ProtocolReceive must find a place to put packet data and copy the data quickly. Shortly after ProtocolReceive returns, when time constraints are not so severe, any underlying miniport driver that made one or more indications with NdisM...IndicateReceive will call the corresponding NdisM..IndicateReceiveComplete. The protocol driver’s ProtocolReceiveComplete function then performs any necessary postprocessing for the original indication(s).

The underlying driver does not remove any headers or trailers from the packet data received on its NIC, nor does it remove any received padding. In other words, a packet can include padding in the data and length indicated to protocols. ProtocolReceive is responsible for detecting and ignoring such padding.

The buffers at HeaderBuffer and LookAheadBuffer passed to ProtocolReceive are read-only and valid only until ProtocolReceive returns control. ProtocolReceive must copy all the indicated data that the driver needs into protocol-allocated storage. Whether a Windows? 2000 or later protocol can copy the indication directly depends on the NDIS_MAC_OPTION_COPY_LOOKAHEAD_DATA flag returned for the OID_GEN_MAC_OPTIONS query. If this flag was set, ProtocolReceive can use NdisMoveMemory to copy the indicated data to its own storage; otherwise, it should use TdiCopyLookaheadData. However, a Windows? 2000 or later protocol can call TdiCopyLookaheadData even if the underlying driver set the NDIS_MAC_OPTION_COPY_LOOKAHEAD_DATA flag.

On a multiprocessor system, this function may execute concurrently on more than one processor. Apply protection (for example, use spinlocks) to critical data structures accessed by this function.

ProtocolReceive runs at IRQL = DISPATCH_LEVEL.

[quote][quote][quote][quote]还是好好看看passthru的例子吧，兄弟！！！！！

看你个头看，要是光看passthru就能解决这个问题我佩服你，blue斑竹以前都没解决。

现在我看了huyu以前发的帖子，问题基本解决。

顺便说一下，你不能解决问题别在这里灌水讲风凉话，一边蹲着去！ [/quote]

哥们，你这样说话很不好吧。如果你passthru真的看明白了，流程也不会不清楚了 [/quote]

我问的那个问题是和流程没有关系的，简单的说
老网卡不会去调用PtReceivePacket，而且不封包，直接传数据
这个请问Passthru里面哪里讲了？你光看Passthru例子能想到
是因为网卡的原因？ [/quote]

ptreceive是什么时候用的、是干吗用的？？你既然都看懂了怎么还会问这么愚蠢的问题。

你这样说话还想让别人回答你的问题么？ [/quote]

瞧你那鸟样，这里是个论坛，虽然你是版主，也不能为所欲为吧？
我没问你问题，你在这拽什么拽，不想回答问题就一边凉快，没人
求你。你这种鸟人都能当版主，我呸！不想和你吵架，坏了这里的
清净。

瞧你那鸟样，这里是个论坛，虽然你是版主，也不能为所欲为吧？
我没问你问题，你在这拽什么拽，不想回答问题就一边凉快，没人
求你。你这种鸟人都能当版主，我呸！不想和你吵架，坏了这里的
清净。

火气那么大？

[quote][quote][quote][quote][quote]还是好好看看passthru的例子吧，兄弟！！！！！

看你个头看，要是光看passthru就能解决这个问题我佩服你，blue斑竹以前都没解决。

现在我看了huyu以前发的帖子，问题基本解决。

顺便说一下，你不能解决问题别在这里灌水讲风凉话，一边蹲着去！ [/quote]

哥们，你这样说话很不好吧。如果你passthru真的看明白了，流程也不会不清楚了 [/quote]

我问的那个问题是和流程没有关系的，简单的说
老网卡不会去调用PtReceivePacket，而且不封包，直接传数据
这个请问Passthru里面哪里讲了？你光看Passthru例子能想到
是因为网卡的原因？ [/quote]

ptreceive是什么时候用的、是干吗用的？？你既然都看懂了怎么还会问这么愚蠢的问题。

你这样说话还想让别人回答你的问题么？ [/quote]

瞧你那鸟样，这里是个论坛，虽然你是版主，也不能为所欲为吧？
我没问你问题，你在这拽什么拽，不想回答问题就一边凉快，没人
求你。你这种鸟人都能当版主，我呸！不想和你吵架，坏了这里的
清净。 [/quote]
1。是你先在这里出言不逊的。
2.我最讨厌那些不看帮助说明上来就问的人。
懒的理你了。

[quote]还是好好看看passthru的例子吧，兄弟！！！！！

看你个头看，要是光看passthru就能解决这个问题我佩服你，blue斑竹以前都没解决。

现在我看了huyu以前发的帖子，问题基本解决。

顺便说一下，你不能解决问题别在这里灌水讲风凉话，一边蹲着去！ [/quote]
HOHO，这么嚣张，看懂了PASSTHRU的时候，再来发表意见吧。 :o

瞧你那鸟样，这里是个论坛，虽然你是版主，也不能为所欲为吧？
我没问你问题，你在这拽什么拽，不想回答问题就一边凉快，没人
求你。你这种鸟人都能当版主，我呸！不想和你吵架，坏了这里的
清净。

火气好旺了，不要伤身才好。