The outline of your logic looks OK. So, …
To begin, I would be running Network Monitor (part of SMS), because that
will sometimes turn up problems like bad checksums (and might expose
length problems) in things one indicates up.
Next, if this not too much trouble, I would try indicating the changed
packet up immediately (rather than queuing it up for later), but still
setting packet status to NDIS_STATUS_RESOURCES, to preserve the passthru
logic as much as possible. If things still fail, you can exclude the
queuing as part of the problem; conversely, if things succeed, you can
focus on the queuing.
Third, I would examine each flag, on or off, that you’re copying from
the old packet, and try to understand the effect of that flag. It’s
possible one (or more) flag value is inappropriate, particularly if
you’re queuing.
Fourth, and now I’m grasping at straws, I’ve not used NdisTransferData
in my own code (as opposed to what passthru employs). If you have a
reason to suspect that NdisTransferData is not working the way you
expect, you might look at alternative mechanisms for copying packet
data, such as UTILReadOnPacket (see
http://www.ndis.com/papers/ndispacket/readonpacket.htm) or e100DumpPkt
in offload.c in the DDK’s \src\network\ndis\e100bex.
–
If replying by e-mail, please remove “nospam.” from the address.
James Antognini
Windows DDK MVP