Re: Windows Not Respond after calling NDISMIndicateReceivePacket

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Thomas F. Divine [DDK MVP] (tdivine_at_NOpcausaSPAM.com)
Date: 03/06/04


Date: Fri, 5 Mar 2004 20:43:17 -0500

There could be a wide variety of different issues that cause this.

One certainly would be that the packet data was not actually correct. You
are passing a complete Ethernet packet complete with MAC header and payload.
Any mistake in building this would cause the higher levels to ignore the
packet.

In addition to possible fubars in constructing the data, you may also have
made mistakes when constructing the packet that you pass upwards in your
call to NdisMIndicateReceivePacket. Be sure to carefully study the DDK
documentation for NdisMIndicateReceivePacket. You must also do special
handling in your MiniportReturnPacket handler to insure that your own packet
is not returned to the miniport below you - since it did not originate it.

You might also study and consider using NdisMEthIndicateReceive. It is
simpler to use since you do not need to construct a packet to indicate the
packet data upwards.

Of course, study the Windows Server 20003 DDK PassThru sample carefully. In
addition, in this case I would suggest that you study the other NDIS samples
in the DDK. In particular, the miniport samples since they are the ones that
initiate most packets. You can definitely learn from studying them.

Good luck,

Thomas F. Divine
http://www.pcausa.com

"Billy Ng" <anonymous@discussions.microsoft.com> wrote in message
news:0D643380-FFD9-4137-AE6D-4DC8F1A838B1@microsoft.com...
> I am developing a virtual network miniport driver which transfers packets
from the upper protocol driver and a user mode application via
DeviceIoControl calls. I have problem to send packets back up to upper
protocol driver. In testing, I expect windows to respond to the incoming
packets after NDISMIndicateReceivePacket is called. For example, when the
incoming packet is ARP request, I would expect windows to send out ARP
reply. Nothing happens. The same thing happens when I tired to send back a
PING packet.
> In WinDbg, I looked at the Private member of the Packet structure. It
show the correct MDL head and tail pointer (they are the same because the
ARP packet is 32 bytes).
>
> 1) Am I doing the right thing by calling NDISMIndicateReceivePacket to
indicate the incoming packet? I have heard about another call,
NDISMETHIndicateReceive. Should I use that instead?
> 2) Any flag or counter I need to worry about in the packet structure?
>
> Thanks in advance,
> Billy Ng.



Relevant Pages

  • Re: NDIS behaviour
    ... The driver is checking the status upon return from the Indicate call. ... using the NdisMIndicateReceivePacket API. ... the observed working case behavior the control of the packet is returned ... NDIS subsequently calls the miniport driver's MiniportReturnPacket ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Palisade Reference Clock
    ... Have you looked at both firmware docs to insure that there is no changes in the packet data. ... I had to play with this driver to talk to a resolution SMT and just a few changes in bits definition gave me ...
    (comp.protocols.time.ntp)
  • Re: how can I modify the network packet payload?
    ... You got a copy of the packet. ... The packet data is changed when I send and receive both on the ... sender seems hanged there and will not send any more packets. ... I impose the iptable to capture the OUTPUT tcp packet at the sender ...
    (comp.os.linux.networking)
  • How to capture and change packet using linux?
    ... How to capture and change packet using linux? ... I know the "Iptables" can do some of this job, ... the packet data I need do a lot of things to reconstruct a valid ...
    (comp.os.linux.networking)
  • Re: libpcap problem (hdr.len vs tcpdump file size)?
    ... >> the file header and each packet header in addition to the packet ... For the packet data, make sure you copy the captured length ... an additional pcap packet header (struct pcap_pkthdr) -- that's ...
    (comp.os.linux.networking)