From: "Stephan Wolf" Subject: Re: NdisAllocatePacket() anomalies Date: Monday, September 17, 2001 5:34 AM Having read the problem description at PCAUSA, I think this problem might be caused by the fact that deserialized miniport and (by implication) intermediate (IM) drivers are allowed to use the 'MiniportReservedEx' field in an NDIS_PACKET in their send path. The last 4 bytes of the 'MiniportReservedEx' field are at the same offset as the first 4 bytes of the 'WrapperReserved' field. Thus, if such an NDIS_PACKET is used for both send and receive operations in an IM, the 'WrapperReserved' field can contain a value that was previously written in the send path. If the NDIS Wrapper in its receive path relies on that field to be zero, this is clearly a bug then. (Eliyas?) So IM drivers that use the same NDIS_PACKETs for both send and receive operations should save the value of the 'MiniportReservedEx' field before the send operation and restore it in their send comnplete handler. Note that zeroing the 'MiniportReservedEx' field, or, as suggested in the PCAUSA KB article, the complete 'MacReserved' field is dangerous because the 'WrapperReserved[Ex]' field may have been initialized by NdisAllocatePacket() with some meaningful value. I know this is somewhat unlikely to be the case but still not impossible in future version of NDIS. OTOH, though, such NDIS versions should have fixed this problem anyway... Stephan --- On Fri, 31 Aug 2001 01:15:15 -0400, "Thomas F. Divine" wrote: >See in the information at the following URL relates to what you are seeing: > > > >Good luck, >-- >Thomas F. Divine > >PCAUSA - Toolkits & Resources For Network Software Developers >NDIS Protocol - NDIS Intermediate Driver - TDI Client > - > > >"Oleg Smolsky" wrote in >message news:MPG.15f9d0249fbfd0ec989684@202.49.72.50... >> Hello there, >> >> I have just spotted a really strange situation when calling >> NdisAllocatePacket(). I was debugging my NDIS IM driver on win2000 >> which was working alongside with a third-party PPPoE client. >> >> So here is the deal: sometimes a packet discriptor returned by >> NdisAllocatePacket() has WrapperReserved field not set to zeros. So, >> when such a packet is passed to NdisMIndicateReceivePacket() it >> checks weather that field is zero and calls KeBugCheckEx(). >> >> So, has anybody seen anything similar to this? Here are the weird >> things that I have spotted: >> -- this only happens when that PPPoE client is installed >> -- it is a replicatable situation (it seems to happens in a >> particular point of the PPPoE negotiation) >> -- the next packet discriptor returned by NdisAllocatePacket() is >> valid >> >> Thanks in advance, >> Oleg Smolsky. > >