Hi all,
I am doing the LLC/SNAP encapsulation while sending onto the physical medium, the “Ethernet DIX” frames, received from the upper layers in the NDIS miniport . I see that I am always receiving “Ethernet DIX” frames, from the upper stack. Also, on the
receive path, I am stripping out the LLC/SNAP header and taking the “Ethertype” field from the SNAP header and indicating it as part of the Ethernet header, exactly as Stephan mentioned.
Also, I ran the miniport with a checked version of NDIS.sys and I ensured that I am not indicating any packets to the upper layers when the packet filter is set to 0. I have also ensured, that I am zero-padding any short packets (shorter than 46
bytes) , like the ARP packets, to a minimum size of 46 bytes. What I see on the “windump” utility is that on receiving the first ARP request from the network, the upper stack sends an ARP REQUEST to the sender of the first request, rather than sending an
ARP REPLY. After the initial few responses sent by the upper network stack to the ARP REQUEST (which are also ARP REQUESTS to the sender instead of ARP REPLIES), there are no responses from the upper layers for subsequent ARP REQUESTS received from the
sending machine.
Any suggestions, on why the upper layer does not send ARP REPLIES in response to ARP REQUESTS ? Has anybody seen this problem, before ?
Regards,
-Neelay
xxxxx@hotmail.com
(Stephan Wolf) To: “NT Developers Interest List”
Sent by: cc: (bcc: Neelay Das/SVL/SC/PHILIPS)
xxxxx@lis Subject: [ntdev] Re: No response from TCP/IP stack for ARP / ICMP echo requests
ts.osr.com
Classification:
02/13/2002 03:14 AM
Please respond to “NT
Developers Interest
List”
A few things to talk about here:
- Miniports usually don’t modify packet data. If your network medium
is actually “Ethernet”, there is no ned to modify anything in send or
receive packets at all. Just treat them as “raw” data.
- If, however, your network isn’t really Ethernet then you probably
need to modify packets such that they adapt to the underlying network
medium’s constraints.
For instance, since W9X’ TCP/IP stack does not support FDDI, we had to
emulate Ethernet for our SysKonnect FDDI card Miniports.
- “Ethernet II”, also know as “Ethernet DIX” (DEC Intel Xerox" or
“Blue Book Ethernet”, does not use length fields as you claim.
Instead, a type code field is used. Note that there is no “official”
limit for the type code value, ie. values below 1500 are allowed.
However, it is commonly accepted that values below 1500 depict IEEE
802.3 Ethernet:
- “IEEE 802.3 Ethernet” uses a length field, which specifies the
length of the “netto” data following the MAC header, not including the
FCS (Frame Check Sequence).
- If you need a 802.2 header for your medium, then when sending a DIX
type code frame, do as follows:
* add a 802.2 LLC/SNAP header
* set LLC SSAP=DSAP=0xAA
* set LLC Control to 0x03 (unnumbered information)
* set SNAP OUI to 00-00-00
* set SNAP type to original DIX type code
- Now the problem is that when you receive a 802.2 SNAP frame, you
don’t know whether to receive it as 802.3 with SNAP or convert to
DIX. You’ll usually want to have a list of type codes for which you
definitely need to do the conversion, eg.:
* 0800 - IP
* 0806 - ARP
* 8137 - Novell IPX/SPX
* etc.
Convert as follows:
* ONLY if LLC DSAP=SSAP=0x03 AND Control=0x03 AND SNAP OUI = 00-00-00
* strip LLC/SNAP header
* set DIX type code to SNAP type
HTH, Stephan
—
On Tue, 12 Feb 2002 14:42:31 -0800, xxxxx@philips.com wrote:
>
>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@philips.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