Hey,
You might want to try using the checked version of ndis.sys and look for
debug prints. They might indicate the problem you have. I encountered such a
situation in which the checked version of Ndis claimed that my driver was
indicating packets before setting the packet filter…
Please reply if this message is messed up…
Gedon.
-----Original Message-----
From: xxxxx@philips.com [mailto:xxxxx@philips.com]
Sent: Wed, February 13, 2002 12:43 AM
To: NT Developers Interest List
Subject: [ntdev] No response from TCP/IP stack for ARP / ICMP echo
requests
Hi All,
In my NDIS miniport driver, I am indicating packets received from the
NIC, to the upper protocol stack, using NdisMIndicateReceivePacket(). In
MiniportInitializethe medium indicated is NdisMedium802_3 . The problem I
am facing is that the upper
network stack does not send any response for the ARP and ICMP echo requests
received by the NIC and subsequently indicated up by the miniport driver.
While transmitting packets through the miniport driver to the NIC, I
can see that the upper stack always sends Ethernet type II frames to the
miniport i.e. with the “length” field in the IEEE 802.3 MAC header set to a
value more than 1500 which
actually denotes the “Ethertype” field, if the header is interpreted as a
Ethernet type II frame header. The “Ethertype” value is encapsulated in the
frame sent on the physical media in the 802.2 LLC/SNAP header which forms
part of the 802.3 frame
payload.
On the receive side, the miniport driver gets the “Ethertype”
information from the 802.2 LLC/SNAP header which forms part of the received
802.3 frame payload. Then it indicates the frame up as an Ethernet frame,
indicating the “Ethertype” information
as part of the Ethernet header and discards the LLC/SNAP information from
the indicated payload.
I have ensured that, for each buffer I am chaining to the NDIS packet,
I am calling NdisAdjustBufferLength() to set the actual length of the data
in the buffer. Also, I am calling NDIS_SET_PACKET_HEADER_SIZE() to set the
packet header size to 14
bytes and also calling NDIS_SET_PACKET_STATUS() with the status
NDIS_STATUS_SUCCESS, before indicating a single packet up using
NdisMIndicateReceivePacket().
I also checked using the “windump” utility that in the protocol driver
the packets are being received correctly and the utility is able to
distinguish the packet type and parse the fields in the packet. So, it is
slightly weird, that the upper
network stack is not sending any response packets for the received ARP and
ICMP echo request packets. Has anybody come across this problem before ? I
would greatly appreciate any suggestions regarding this issue.
Thanks in advance,
-Neelay
P.S. : I am testing the miniport on Win2k.
You are currently subscribed to ntdev as: xxxxx@intel.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com