Hi All,
I am developing a W2K NDIS Intermediate driver and have a question. I want
to create a packet within the intermediate driver which I can pass up the
protocol stack to the TCP/IP stack sitting above it. I create a packet with
the following calls:
NdisAllocatePacket(&Status, &g_pArpPacket,
pAdapt->SendPacketPoolHandle)NdisAllocateBuffer(&Status, &g_pARPBuffer,
pAdapt->RecvBufferPoolHandle, g_pArpMem, sizeof(SArpPacket));
NDIS_SET_PACKET_HEADER_SIZE(g_pArpPacket,14);
NDIS_SET_PACKET_MEDIA_SPECIFIC_INFO(g_pArpPacket, NULL, 0 );
NdisChainBufferAtBack(g_pArpPacket,g_pARPBuffer);
and fill in the IP Packet header and data, but when I call:
NdisMIndicateReceivePacket(pAdapt->MiniportHandle, &g_pArpPacket,1);
the machine just hangs. Has anyone any ideas what I may be doing wrong? The
driver model is similar to NT, so if anyone had experience of NT NDIS
drivers it may also be relevant.
Thanks in advance,
Gavin Button
You might try setting the original packet in your new packet:
NDIS_SET_ORIGINAL_PACKET( pNewPacket, pNewPacket );
I also set the packet’s status using NDIS_SET_PACKET_STATUS and the time
using NDIS_SET_PACKET_TIME_RECEIVED.
You might also run on checked build. It may give some insight. Some adapters
offer hardware shecksum task offload. Of course, your IM does NOT. So some
requests have to be spoofed to make sure that the higher-level protocol
doesn’t reject the packet because your IM didn’t do the checksum.
Finally, use Windows 2000 DDK SP1 and run on Windows 2000 SP1.
If that doesn’t work, then PCAUSA does license NDIS IM driver samples for NT
and 2000. There was more work then I expected in moving from a do-nothing
PassThru IM to one that was still PassThru - but using COMPLETELY new
packets, buffers and data memory.
Good luck,
Thomas F. Divine
PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - TDI Client - Windows 95 Redirector
http:
----- Original Message -----
From: Gavin Button
To: NT Developers Interest List
Sent: Monday, October 16, 2000 10:24 AM
Subject: [ntdev] NdisMIndicateReceivePacket()
> Hi All,
>
> I am developing a W2K NDIS Intermediate driver and have a question. I want
> to create a packet within the intermediate driver which I can pass up the
> protocol stack to the TCP/IP stack sitting above it. I create a packet
with
> the following calls:
>
> NdisAllocatePacket(&Status, &g_pArpPacket,
> pAdapt->SendPacketPoolHandle)NdisAllocateBuffer(&Status, &g_pARPBuffer,
> pAdapt->RecvBufferPoolHandle, g_pArpMem, sizeof(SArpPacket));
> NDIS_SET_PACKET_HEADER_SIZE(g_pArpPacket,14);
> NDIS_SET_PACKET_MEDIA_SPECIFIC_INFO(g_pArpPacket, NULL, 0 );
> NdisChainBufferAtBack(g_pArpPacket,g_pARPBuffer);
>
> and fill in the IP Packet header and data, but when I call:
>
> NdisMIndicateReceivePacket(pAdapt->MiniportHandle, &g_pArpPacket,1);
>
> the machine just hangs. Has anyone any ideas what I may be doing wrong?
The
> driver model is similar to NT, so if anyone had experience of NT NDIS
> drivers it may also be relevant.
>
> Thanks in advance,
>
> Gavin Button
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@pcausa.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
></http:>
Hi Gavin,
Just checking the obvious. Pools allocated from the NP Pool,g_pArpMem
already allocated, not holding any spinlock while trying any calls ?
Rod.
-----Original Message-----
From: Gavin Button [mailto:xxxxx@panasonic-pmdc.co.uk]
Sent: Tuesday, 17 October 2000 1:25 am
To: NT Developers Interest List
Subject: [ntdev] NdisMIndicateReceivePacket()
Hi All,
I am developing a W2K NDIS Intermediate driver and have a question. I want
to create a packet within the intermediate driver which I can pass up the
protocol stack to the TCP/IP stack sitting above it. I create a packet with
the following calls:
NdisAllocatePacket(&Status, &g_pArpPacket,
pAdapt->SendPacketPoolHandle)NdisAllocateBuffer(&Status, &g_pARPBuffer,
pAdapt->RecvBufferPoolHandle, g_pArpMem, sizeof(SArpPacket));
NDIS_SET_PACKET_HEADER_SIZE(g_pArpPacket,14);
NDIS_SET_PACKET_MEDIA_SPECIFIC_INFO(g_pArpPacket, NULL, 0 );
NdisChainBufferAtBack(g_pArpPacket,g_pARPBuffer);
and fill in the IP Packet header and data, but when I call:
NdisMIndicateReceivePacket(pAdapt->MiniportHandle, &g_pArpPacket,1);
the machine just hangs. Has anyone any ideas what I may be doing wrong? The
driver model is similar to NT, so if anyone had experience of NT NDIS
drivers it may also be relevant.
Thanks in advance,
Gavin Button
You are currently subscribed to ntdev as: xxxxx@mobilesoft.com.au
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Hi Rod,
Thanks for your comments. I have double checked that the pools and memory
are allocated and am fairly sure that I am not holding a spin lock. What do
you mean by the NP pool?
Thanks
Gavin Button
Subject: RE: NdisMIndicateReceivePacket()
From: Rodney Sigmund
Date: Tue, 17 Oct 2000 11:28:58 +1100
X-Message-Number: 17
Hi Gavin,
Just checking the obvious. Pools allocated from the NP Pool,g_pArpMem
already allocated, not holding any spinlock while trying any calls ?
Rod.
-----Original Message-----
From: Gavin Button [mailto:xxxxx@panasonic-pmdc.co.uk]
Sent: Tuesday, 17 October 2000 1:25 am
To: NT Developers Interest List
Subject: [ntdev] NdisMIndicateReceivePacket()
Hi All,
I am developing a W2K NDIS Intermediate driver and have a question. I want
to create a packet within the intermediate driver which I can pass up the
protocol stack to the TCP/IP stack sitting above it. I create a packet with
the following calls:
NdisAllocatePacket(&Status, &g_pArpPacket,
pAdapt->SendPacketPoolHandle)NdisAllocateBuffer(&Status, &g_pARPBuffer,
pAdapt->RecvBufferPoolHandle, g_pArpMem, sizeof(SArpPacket));
NDIS_SET_PACKET_HEADER_SIZE(g_pArpPacket,14);
NDIS_SET_PACKET_MEDIA_SPECIFIC_INFO(g_pArpPacket, NULL, 0 );
NdisChainBufferAtBack(g_pArpPacket,g_pARPBuffer);
and fill in the IP Packet header and data, but when I call:
NdisMIndicateReceivePacket(pAdapt->MiniportHandle, &g_pArpPacket,1);
the machine just hangs. Has anyone any ideas what I may be doing wrong? The
driver model is similar to NT, so if anyone had experience of NT NDIS
drivers it may also be relevant.
Thanks in advance,
Gavin Button
Are you calling NdisMIndicateReceivePacket() at DPC Level?
Robin
-----Original Message-----
From: Gavin Button [mailto:xxxxx@panasonic-pmdc.co.uk]
Sent: Tuesday, October 17, 2000 12:01 PM
To: NT Developers Interest List
Cc: xxxxx@mobilesoft.com.au
Subject: [ntdev] Re: NdisMIndicateReceivePacket()
Hi Rod,
Thanks for your comments. I have double checked that the
pools and memory
are allocated and am fairly sure that I am not holding a spin
lock. What do
you mean by the NP pool?
Thanks
Gavin Button
Subject: RE: NdisMIndicateReceivePacket()
From: Rodney Sigmund
> Date: Tue, 17 Oct 2000 11:28:58 +1100
> X-Message-Number: 17
>
>
> Hi Gavin,
>
> Just checking the obvious. Pools allocated from the NP Pool,g_pArpMem
> already allocated, not holding any spinlock while trying any calls ?
>
> Rod.
>
> -----Original Message-----
> From: Gavin Button [mailto:xxxxx@panasonic-pmdc.co.uk]
> Sent: Tuesday, 17 October 2000 1:25 am
> To: NT Developers Interest List
> Subject: [ntdev] NdisMIndicateReceivePacket()
>
>
> Hi All,
>
> I am developing a W2K NDIS Intermediate driver and have a
> question. I want
> to create a packet within the intermediate driver which I can
> pass up the
> protocol stack to the TCP/IP stack sitting above it. I create
> a packet with
> the following calls:
>
> NdisAllocatePacket(&Status, &g_pArpPacket,
> pAdapt->SendPacketPoolHandle)NdisAllocateBuffer(&Status,
> &g_pARPBuffer,
> pAdapt->RecvBufferPoolHandle, g_pArpMem, sizeof(SArpPacket));
> NDIS_SET_PACKET_HEADER_SIZE(g_pArpPacket,14);
> NDIS_SET_PACKET_MEDIA_SPECIFIC_INFO(g_pArpPacket, NULL, 0 );
> NdisChainBufferAtBack(g_pArpPacket,g_pARPBuffer);
>
> and fill in the IP Packet header and data, but when I call:
>
> NdisMIndicateReceivePacket(pAdapt->MiniportHandle, &g_pArpPacket,1);
>
> the machine just hangs. Has anyone any ideas what I may be
> doing wrong? The
> driver model is similar to NT, so if anyone had experience of NT NDIS
> drivers it may also be relevant.
>
> Thanks in advance,
>
> Gavin Button
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@exgate.tek.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
Thanks for the suggestions, I have tried what you said but still have the
same problem.
I couldnt find a service pack 1 for the DDK, but installed the latest MSDN
version October 2000 (Build 2195).
I ran the code through the Debugger and received the following error:
*** Assertion failed: PNDIS_REFERENCE_FROM_PNDIS_PACKET(Packet)->RefCount ==
0
*** Source File: D:\nt\private\ntos\ndis\ndis\efilter.c, line 2025
Has anyone got an idea what this could mean?
Thanks again,
Gavin Button
Subject: Re: NdisMIndicateReceivePacket()
From: “Thomas F. Divine”
Date: Mon, 16 Oct 2000 11:43:13 -0400
X-Message-Number: 14
You might try setting the original packet in your new packet:
NDIS_SET_ORIGINAL_PACKET( pNewPacket, pNewPacket );
I also set the packet’s status using NDIS_SET_PACKET_STATUS and the time
using NDIS_SET_PACKET_TIME_RECEIVED.
You might also run on checked build. It may give some insight. Some adapters
offer hardware shecksum task offload. Of course, your IM does NOT. So some
requests have to be spoofed to make sure that the higher-level protocol
doesn’t reject the packet because your IM didn’t do the checksum.
Finally, use Windows 2000 DDK SP1 and run on Windows 2000 SP1.
If that doesn’t work, then PCAUSA does license NDIS IM driver samples for NT
and 2000. There was more work then I expected in moving from a do-nothing
PassThru IM to one that was still PassThru - but using COMPLETELY new
packets, buffers and data memory.
Good luck,
Thomas F. Divine
PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - TDI Client - Windows 95 Redirector
http:
----- Original Message -----
From: Gavin Button
To: NT Developers Interest List
Sent: Monday, October 16, 2000 10:24 AM
Subject: [ntdev] NdisMIndicateReceivePacket()
> Hi All,
>
> I am developing a W2K NDIS Intermediate driver and have a question. I want
> to create a packet within the intermediate driver which I can pass up the
> protocol stack to the TCP/IP stack sitting above it. I create a packet
with
> the following calls:
>
> NdisAllocatePacket(&Status, &g_pArpPacket,
> pAdapt->SendPacketPoolHandle)NdisAllocateBuffer(&Status, &g_pARPBuffer,
> pAdapt->RecvBufferPoolHandle, g_pArpMem, sizeof(SArpPacket));
> NDIS_SET_PACKET_HEADER_SIZE(g_pArpPacket,14);
> NDIS_SET_PACKET_MEDIA_SPECIFIC_INFO(g_pArpPacket, NULL, 0 );
> NdisChainBufferAtBack(g_pArpPacket,g_pARPBuffer);
>
> and fill in the IP Packet header and data, but when I call:
>
> NdisMIndicateReceivePacket(pAdapt->MiniportHandle, &g_pArpPacket,1);
>
> the machine just hangs. Has anyone any ideas what I may be doing wrong?
The
> driver model is similar to NT, so if anyone had experience of NT NDIS
> drivers it may also be relevant.
>
> Thanks in advance,
>
> Gavin Button
></http:>
Hi Gavin,
I meant the nonpaged pool. Good luck.
Rod.
-----Original Message-----
From: Gavin Button [mailto:xxxxx@panasonic-pmdc.co.uk]
Sent: Tuesday, 17 October 2000 9:01 pm
To: NT Developers Interest List
Cc: xxxxx@mobilesoft.com.au
Subject: [ntdev] Re: NdisMIndicateReceivePacket()
Hi Rod,
Thanks for your comments. I have double checked that the pools and memory
are allocated and am fairly sure that I am not holding a spin lock. What do
you mean by the NP pool?
Thanks
Gavin Button
Subject: RE: NdisMIndicateReceivePacket()
From: Rodney Sigmund
Date: Tue, 17 Oct 2000 11:28:58 +1100
X-Message-Number: 17
Hi Gavin,
Just checking the obvious. Pools allocated from the NP Pool,g_pArpMem
already allocated, not holding any spinlock while trying any calls ?
Rod.
-----Original Message-----
From: Gavin Button [mailto:xxxxx@panasonic-pmdc.co.uk]
Sent: Tuesday, 17 October 2000 1:25 am
To: NT Developers Interest List
Subject: [ntdev] NdisMIndicateReceivePacket()
Hi All,
I am developing a W2K NDIS Intermediate driver and have a question. I want
to create a packet within the intermediate driver which I can pass up the
protocol stack to the TCP/IP stack sitting above it. I create a packet with
the following calls:
NdisAllocatePacket(&Status, &g_pArpPacket,
pAdapt->SendPacketPoolHandle)NdisAllocateBuffer(&Status, &g_pARPBuffer,
pAdapt->RecvBufferPoolHandle, g_pArpMem, sizeof(SArpPacket));
NDIS_SET_PACKET_HEADER_SIZE(g_pArpPacket,14);
NDIS_SET_PACKET_MEDIA_SPECIFIC_INFO(g_pArpPacket, NULL, 0 );
NdisChainBufferAtBack(g_pArpPacket,g_pARPBuffer);
and fill in the IP Packet header and data, but when I call:
NdisMIndicateReceivePacket(pAdapt->MiniportHandle, &g_pArpPacket,1);
the machine just hangs. Has anyone any ideas what I may be doing wrong? The
driver model is similar to NT, so if anyone had experience of NT NDIS
drivers it may also be relevant.
Thanks in advance,
Gavin Button
—
You are currently subscribed to ntdev as: xxxxx@mobilesoft.com.au
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
You can try to find where is failed reference stored, the code which
accesses it should be just before RtlAssert() call. Maybe you will see what
is wrong immediatelly. It can be some reasonable number as 1, 2 or -1 which
would imply missing or superfluous derefence (i.e. violating some NDIS
rule). If it is some strange value, it means uninitialized or rewritten
memory.
BTW, when you’re calling NdisAllocatePacketPool(), is the
ProtocolReservedLength value at least 16?
Best regards,
Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]
From: Gavin Button[SMTP:xxxxx@panasonic-pmdc.co.uk]
Reply To: NT Developers Interest List
Sent: Tuesday, October 17, 2000 15:05
To: NT Developers Interest List
Cc: xxxxx@pcausa.com
Subject: [ntdev] Re: NdisMIndicateReceivePacket()
Thanks for the suggestions, I have tried what you said but still have the
same problem.
I couldnt find a service pack 1 for the DDK, but installed the latest MSDN
version October 2000 (Build 2195).
I ran the code through the Debugger and received the following error:
*** Assertion failed: PNDIS_REFERENCE_FROM_PNDIS_PACKET(Packet)->RefCount
0
*** Source File: D:\nt\private\ntos\ndis\ndis\efilter.c, line 2025
Has anyone got an idea what this could mean?
Thanks again,
Gavin Button
Subject: Re: NdisMIndicateReceivePacket()
From: “Thomas F. Divine”
> Date: Mon, 16 Oct 2000 11:43:13 -0400
> X-Message-Number: 14
>
> You might try setting the original packet in your new packet:
>
> NDIS_SET_ORIGINAL_PACKET( pNewPacket, pNewPacket );
>
> I also set the packet’s status using NDIS_SET_PACKET_STATUS and the time
> using NDIS_SET_PACKET_TIME_RECEIVED.
>
> You might also run on checked build. It may give some insight. Some
> adapters
> offer hardware shecksum task offload. Of course, your IM does NOT. So some
> requests have to be spoofed to make sure that the higher-level protocol
> doesn’t reject the packet because your IM didn’t do the checksum.
>
> Finally, use Windows 2000 DDK SP1 and run on Windows 2000 SP1.
>
> If that doesn’t work, then PCAUSA does license NDIS IM driver samples for
> NT
> and 2000. There was more work then I expected in moving from a do-nothing
> PassThru IM to one that was still PassThru - but using COMPLETELY new
> packets, buffers and data memory.
>
> Good luck,
>
> Thomas F. Divine
>
> PCAUSA - Toolkits & Resources For Network Software Developers
> NDIS Protocol - TDI Client - Windows 95 Redirector
> http:
>
> ----- Original Message -----
> From: Gavin Button
> To: NT Developers Interest List
> Sent: Monday, October 16, 2000 10:24 AM
> Subject: [ntdev] NdisMIndicateReceivePacket()
>
>
> > Hi All,
> >
> > I am developing a W2K NDIS Intermediate driver and have a question. I
> want
> > to create a packet within the intermediate driver which I can pass up
> the
> > protocol stack to the TCP/IP stack sitting above it. I create a packet
> with
> > the following calls:
> >
> > NdisAllocatePacket(&Status, &g_pArpPacket,
> > pAdapt->SendPacketPoolHandle)NdisAllocateBuffer(&Status, &g_pARPBuffer,
> > pAdapt->RecvBufferPoolHandle, g_pArpMem, sizeof(SArpPacket));
> > NDIS_SET_PACKET_HEADER_SIZE(g_pArpPacket,14);
> > NDIS_SET_PACKET_MEDIA_SPECIFIC_INFO(g_pArpPacket, NULL, 0 );
> > NdisChainBufferAtBack(g_pArpPacket,g_pARPBuffer);
> >
> > and fill in the IP Packet header and data, but when I call:
> >
> > NdisMIndicateReceivePacket(pAdapt->MiniportHandle, &g_pArpPacket,1);
> >
> > the machine just hangs. Has anyone any ideas what I may be doing wrong?
> The
> > driver model is similar to NT, so if anyone had experience of NT NDIS
> > drivers it may also be relevant.
> >
> > Thanks in advance,
> >
> > Gavin Button
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rkk.cz
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
></http:>
Hi,
Its is called from within the ProtocolReceive handler, which gets called
when incoming packets are received by the driver. Does this make it DPC
level? If so, does this make a difference?
Gavin
Subject: Re: NdisMIndicateReceivePacket()
From: xxxxx@exgate.tek.com
Date: Tue, 17 Oct 2000 14:30:32 +0200
X-Message-Number: 6
Are you calling NdisMIndicateReceivePacket() at DPC Level?
Robin
Hi,
Thanks for the reply.
I was using NdisAllocatePacketPoolEX(), but changed to using
NdisAllocatePacketPool() with ProtocolReserved set to 16, and still have the
same problem.
I was wondering how I can to track down this problem further, as you
suggest, as I dont have the source code for this system module??
The debugger also gave some additional output if you ignore the error:
‘***NDIS*** : Miniport Xircom CreditCard Ethernet Adapter 10/100 - Mobile
IP - Mobile Host - Indicating packet not owned by it’
Gavin Button
Subject: Re: NdisMIndicateReceivePacket()
From: “Vodicka, Michal”
Date: Wed, 18 Oct 2000 01:32:19 +0200
X-Message-Number: 15
You can try to find where is failed reference stored, the code which
accesses it should be just before RtlAssert() call. Maybe you will see what
is wrong immediatelly. It can be some reasonable number as 1, 2 or -1 which
would imply missing or superfluous derefence (i.e. violating some NDIS
rule). If it is some strange value, it means uninitialized or rewritten
memory.
BTW, when you’re calling NdisAllocatePacketPool(), is the
ProtocolReservedLength value at least 16?
Best regards,
Michal Vodicka
Veridicom
From DDK docs:
Serialized callers of NdisMIndicateReceivePacket must run at IRQL
DISPATCH_LEVEL. Deserialized callers of NdisMIndicateReceivePacket can run
at IRQL <= DISPATCH_LEVEL
You can use KeGetCurrentIrql() to check currect IRQL. ProtocolReceive() is
probably called on DISPATCH_LEVEL but I would check it in any case. However,
it doesn’t seem as source of your problem.
Best regards,
Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]
From: Gavin Button[SMTP:xxxxx@panasonic-pmdc.co.uk]
Reply To: NT Developers Interest List
Sent: Wednesday, October 18, 2000 11:16
To: NT Developers Interest List
Cc: xxxxx@exgate.tek.com
Subject: [ntdev] Re: NdisMIndicateReceivePacket()
Hi,
Its is called from within the ProtocolReceive handler, which gets
called
when incoming packets are received by the driver. Does this make it DPC
level? If so, does this make a difference?
Gavin
Subject: Re: NdisMIndicateReceivePacket()
From: xxxxx@exgate.tek.com
Date: Tue, 17 Oct 2000 14:30:32 +0200
X-Message-Number: 6
Are you calling NdisMIndicateReceivePacket() at DPC Level?
Robin
You are currently subscribed to ntdev as: xxxxx@rkk.cz
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> ----------
From: Gavin Button[SMTP:xxxxx@panasonic-pmdc.co.uk]
Reply To: NT Developers Interest List
Sent: Wednesday, October 18, 2000 15:54
To: NT Developers Interest List
Cc: xxxxx@rkk.cz
Subject: [ntdev] Re: NdisMIndicateReceivePacket()
Hi,
Thanks for the reply.
I was using NdisAllocatePacketPoolEX(), but changed to using
NdisAllocatePacketPool() with ProtocolReserved set to 16, and still have
the
same problem.
You can continue using NdisAllocatePacketPoolEx(), the rule is the same
(ProtocolReservedLength >= 16).
I was wondering how I can to track down this problem further, as you
suggest, as I dont have the source code for this system module??
On assembly level, of course. It is the easiest and sometimes the only way
how to find out the source of problem which caused RtlAssert(). Assert
expression itself is mostly meaningful only if you have source code.
The debugger also gave some additional output if you ignore the error:
‘***NDIS*** : Miniport Xircom CreditCard Ethernet Adapter 10/100 - Mobile
IP - Mobile Host - Indicating packet not owned by it’
It can be important. Maybe NDIS expects the packet originator must be a
driver layered below your one. Try to set original packet
(NDIS_SET_ORIGINAL_PACKET) to one which caused your ProtocolReceive() call.
See passthru DDK example and PtReceive() handler. You should follow this
logic (Packet = NdisGetReceivedPacket(), NDIS_SET_ORIGINAL_PACKET(…,
NDIS_GET_ORIGINAL_PACKET(Packet)).
Best regards,
Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]
Gavin Button
Subject: Re: NdisMIndicateReceivePacket()
From: “Vodicka, Michal”
> Date: Wed, 18 Oct 2000 01:32:19 +0200
> X-Message-Number: 15
>
> You can try to find where is failed reference stored, the code which
> accesses it should be just before RtlAssert() call. Maybe you will see
> what
> is wrong immediatelly. It can be some reasonable number as 1, 2 or -1
> which
> would imply missing or superfluous derefence (i.e. violating some NDIS
> rule). If it is some strange value, it means uninitialized or rewritten
> memory.
>
> BTW, when you’re calling NdisAllocatePacketPool(), is the
> ProtocolReservedLength value at least 16?
>
> Best regards,
>
> Michal Vodicka
> Veridicom
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rkk.cz
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
----- Original Message -----
From: Vodicka, Michal
To: NT Developers Interest List
Sent: Wednesday, October 18, 2000 8:19 PM
Subject: [ntdev] Re: NdisMIndicateReceivePacket()
> > The debugger also gave some additional output if you ignore the error:
> >
> > ’ NDIS : Miniport Xircom CreditCard Ethernet Adapter 10/100 -
Mobile
> > IP - Mobile Host - Indicating packet not owned by it’
> >
> It can be important. Maybe NDIS expects the packet originator must be a
> driver layered below your one. Try to set original packet
> (NDIS_SET_ORIGINAL_PACKET) to one which caused your ProtocolReceive()
call.
> See passthru DDK example and PtReceive() handler. You should follow this
> logic (Packet = NdisGetReceivedPacket(), NDIS_SET_ORIGINAL_PACKET(…,
> NDIS_GET_ORIGINAL_PACKET(Packet)).
>
Interesting idea.
But, IIRC the poster is indicating a packet that he created himself. If you
set the original packet to the packet received from the adapter below
instead of the new packet that you’re indicating, what kind of trouble does
that cause? For example, won’t some date be fetched from the lower packet
instead of the newly constructed packet?
Has the original poster tried this on a different adapter?
Perhaps there’s a load order problem here. That is, perhaps the “Mobile IP -
Mobile Host” is itself a NDIS IM and the poster’s driver should be one level
up.
Just musing…
Regards,
Thomas F. Divine
PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - TDI Client - Windows 95 Redirector
http:</http:>
----- Original Message -----
From: Vodicka, Michal
To: NT Developers Interest List
Sent: Wednesday, October 18, 2000 8:50 PM
Subject: [ntdev] Re: NdisMIndicateReceivePacket()
> > ----------
> > From: Thomas F. Divine[SMTP:xxxxx@pcausa.com]
> > Reply To: NT Developers Interest List
> > Sent: Thursday, October 19, 2000 02:28
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: NdisMIndicateReceivePacket()
> >
> > ----- Original Message -----
> > From: Vodicka, Michal
> > To: NT Developers Interest List
> > Sent: Wednesday, October 18, 2000 8:19 PM
> > Subject: [ntdev] Re: NdisMIndicateReceivePacket()
> >
> >
> But, IIRC the poster is indicating a packet that he created himself. If
> > you
> > set the original packet to the packet received from the adapter below
> > instead of the new packet that you’re indicating, what kind of trouble
> > does
> > that cause? For example, won’t some date be fetched from the lower
packet
> > instead of the newly constructed packet?
> >
> I’m not quite sure about the purpose of original packet, DKK docs isn’t
very
> clear in this area. From NDIS_GET/SET_ORIGINAL_PACKET macros docs it seems
> that original packet should be used for accessing OOB data. It is logical
> because there is no way in ProtocolReceive() handler how to transfer OOB
> data block.
>
> Accessing original packet data would be a big mistake in any case and
there
> is no reason (I hope) to do it. It would violate whole layered driver
stack
> concept and would work only if you only rechain original packet buffers as
> passthru does.
>
> Maybe he should try to set original packet to NULL (is this field
> initialized after NdisAllocatePacket()?).
>
I have tried that with no joy.
What I have seen that works is:
1.) The method that you suggested (like DDK PassThru)
2.) Seting the original packet to the newly cerated packet (which I
suggested that the poster should do).
Setting to NULL didn’t work for me.
I think there’s a higher level IM that’s expecting something special in
OOB…
Regards,
Thomas F. Divine
PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - TDI Client - Windows 95 Redirector
http:</http:>
> ----------
From: Thomas F. Divine[SMTP:xxxxx@pcausa.com]
Reply To: NT Developers Interest List
Sent: Thursday, October 19, 2000 3:27 AM
To: NT Developers Interest List
Subject: [ntdev] Re: NdisMIndicateReceivePacket()
> Maybe he should try to set original packet to NULL (is this field
> initialized after NdisAllocatePacket()?).
>
I have tried that with no joy.
No surprise, if I think more about it I would expect BSOD somewhere in NDIS
What I have seen that works is:
1.) The method that you suggested (like DDK PassThru)
I’m using this method in encryption IM driver without problems (which
doesn’t imply anything about correctness).
2.) Seting the original packet to the newly cerated packet (which I
suggested that the poster should do).
Setting to NULL didn’t work for me.
I think there’s a higher level IM that’s expecting something special in
OOB…
Based on assert and the next message it seems he uses checked NDIS version
which has some expectation about original packet (probably).
Best regards,
Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]
One other possibility is that the poster returned a packet to the lower
level miniport that didn’t actually belong to the lower level miniport.
That’s probably remote.
Thomas
----- Original Message -----
From: Vodicka, Michal
To: NT Developers Interest List
Sent: Wednesday, October 18, 2000 9:38 PM
Subject: [ntdev] Re: NdisMIndicateReceivePacket()
> > ----------
> > From: Thomas F. Divine[SMTP:xxxxx@pcausa.com]
> > Reply To: NT Developers Interest List
> > Sent: Thursday, October 19, 2000 3:27 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: NdisMIndicateReceivePacket()
> >
> > > Maybe he should try to set original packet to NULL (is this field
> > > initialized after NdisAllocatePacket()?).
> > >
> > I have tried that with no joy.
> >
> No surprise, if I think more about it I would expect BSOD somewhere in
NDIS
>
>
> > What I have seen that works is:
> >
> > 1.) The method that you suggested (like DDK PassThru)
> >
> I’m using this method in encryption IM driver without problems (which
> doesn’t imply anything about correctness).
>
> > 2.) Seting the original packet to the newly cerated packet (which I
> > suggested that the poster should do).
> >
> > Setting to NULL didn’t work for me.
> >
> > I think there’s a higher level IM that’s expecting something special in
> > OOB…
> >
> Based on assert and the next message it seems he uses checked NDIS version
> which has some expectation about original packet (probably).
>
> Best regards,
>
> Michal Vodicka
> Veridicom
> (RKK - Skytale)
> [WWW: http://www.veridicom.com , http://www.skytale.com]
>
>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@pcausa.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
You, were right. My ReturnPacket handler was in turn returning the packets
to a lower layer, which it shouldnnt have been doing as they were created
within my driver.
Thanks to everyone who helped with this problem.
Regards,
Gavin Button
Subject: Re: NdisMIndicateReceivePacket()
From: “Thomas F. Divine”
Date: Wed, 18 Oct 2000 21:40:52 -0400
X-Message-Number: 24
One other possibility is that the poster returned a packet to the lower
level miniport that didn’t actually belong to the lower level miniport.
That’s probably remote.
Thomas