Memory leak when receiving from NDISWAN

I have an IM driver based on PassThru. In specific cases, when receiving a
packet, I need to create a new one and send it on a different interface.
When that occurs I do not indicate the received packet and "eat" it.

I made some minor changes to the PtReceive function so that I call my
parsing function (which extracts the data from the packet and makes
decisions depending on its contents). Depending on the return value of my
parsing function, I call NdisMIndicateReceivePacket or not and then proceed
with the rest of the PtReceive code.

The issue I'm having is that, when receiving packets from NDISWAN, NonPaged
memory gets eaten, 4K at a time. I'll summarize what the code path looks
like:

PtReceive()
{
// (normal PassThru code that wraps original packet data "Packet" in new
packet descriptor "MyPacket")
if(!MyParsingFunction(MyPacket, ...))
{
NdisMIndicateReceivePacket(pAdapt->MiniportHandle, &MyPacket, 1);
}
// (rest of PassThru execution, which calls NdisDprFreePacket, breaks
and then returns)
}

MyParsingFunction()
{
// (code that copies all the data from the packet into a flat buffer -
no changes are made to the packet itself)
// if buffer contains specific data
{
NdisDprAllocatePacket(&Status, &NewPacket,
TargetAdapter->SendPacketPoolHandle);
if(Status == NDIS_STATUS_SUCCESS)
{
//... rest of the code that builds a new packet and calls
NdisSend with it
NdisDprFreePacket(NewPacket);
}
}
}

This code works perfectly well with other adapters (whether they be cabled
LAN or wireless) but as soon as the packets originate from NDISWAN (in our
case, L2TP, PPPoE or straight PPP) it starts to leak NonPagedPool by 4K
chunks. Note that removing the NdisDprAllocatePacket code block makes the
leak DISAPPEAR.

I ran the Pooltag utility that comes with the 2003 DDK and the leak was
located in the WanE tag. Very little information was available regarding
this tag, but I found a tag list that described it as "LoopbackDesc"
(loopback descriptors?).

Any ideas? I keep digging up 2-3 old newsgroup threads that mention similar
issues but fail to find a solution).

--
-----
Benoît Bousquet
(e-mail address is invalid)