Ndis Driver problem

hello,
i am writting a network driver,and facing problem in ICMP resolve.
can anybody tell me how to form a proper packet in receive path.?
it is a miniport - ndis driver.

first i am creating a packet,
NdisAllocateBuffer();
NdisAllocatePacket();
I copied the ICMP packet of 98 bytes,,
then set the status of the packet to NDIS_SET_PACKET_STATUS(
packet,,_SUCCESS)
then attached the packet at front,
and then send it to upper layer ,,,
NdisMIndicateReceive();

Am i missing something? if yes then tell me how to resolve it,?

thanks,,
from
Hitesh

Maxim
Thu Dec 21 06:35:54 CST 2006

NDIS_SET_PACKET_HEADER_SIZE is also a must.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"hitesh" <hitesh.ughreja@gmail.com> wrote in message
news:1166619985.208731.246740@a3g2000cwd.googlegroups.com...
> hello,
> i am writting a network driver,and facing problem in ICMP resolve.
> can anybody tell me how to form a proper packet in receive path.?
> it is a miniport - ndis driver.
>
> first i am creating a packet,
> NdisAllocateBuffer();
> NdisAllocatePacket();
> I copied the ICMP packet of 98 bytes,,
> then set the status of the packet to NDIS_SET_PACKET_STATUS(
> packet,,_SUCCESS)
> then attached the packet at front,
> and then send it to upper layer ,,,
> NdisMIndicateReceive();
>
> Am i missing something? if yes then tell me how to resolve it,?
>
> thanks,,
> from
> Hitesh
>

hitesh
Thu Dec 21 07:15:28 CST 2006

hello Maxim,
thanks for the reply,
but one thing,, please note,
i am not creating packet every time and deleting but,
at starting i have created a packet and after that i am using the same
packet for all allocated buffers. os in initialization i have set the
header size to 14 bytes.
actually i am not sure about the length,,? as per my information we
have to set this value to 14 bytes constant,, isn't it?
please reply,,
thanks
from
Hitesh


Maxim S. Shatskih wrote:
> NDIS_SET_PACKET_HEADER_SIZE is also a must.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
> "hitesh" <hitesh.ughreja@gmail.com> wrote in message
> news:1166619985.208731.246740@a3g2000cwd.googlegroups.com...
> > hello,
> > i am writting a network driver,and facing problem in ICMP resolve.
> > can anybody tell me how to form a proper packet in receive path.?
> > it is a miniport - ndis driver.
> >
> > first i am creating a packet,
> > NdisAllocateBuffer();
> > NdisAllocatePacket();
> > I copied the ICMP packet of 98 bytes,,
> > then set the status of the packet to NDIS_SET_PACKET_STATUS(
> > packet,,_SUCCESS)
> > then attached the packet at front,
> > and then send it to upper layer ,,,
> > NdisMIndicateReceive();
> >
> > Am i missing something? if yes then tell me how to resolve it,?
> >
> > thanks,,
> > from
> > Hitesh
> >

Maxim
Thu Dec 21 09:45:41 CST 2006

I would suggest to call all init things before each NdisSend, not once at
packet allocation.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"hitesh" <hitesh.ughreja@gmail.com> wrote in message
news:1166706928.305124.83980@73g2000cwn.googlegroups.com...
> hello Maxim,
> thanks for the reply,
> but one thing,, please note,
> i am not creating packet every time and deleting but,
> at starting i have created a packet and after that i am using the same
> packet for all allocated buffers. os in initialization i have set the
> header size to 14 bytes.
> actually i am not sure about the length,,? as per my information we
> have to set this value to 14 bytes constant,, isn't it?
> please reply,,
> thanks
> from
> Hitesh
>
>
> Maxim S. Shatskih wrote:
> > NDIS_SET_PACKET_HEADER_SIZE is also a must.
> >
> > --
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > maxim@storagecraft.com
> > http://www.storagecraft.com
> >
> > "hitesh" <hitesh.ughreja@gmail.com> wrote in message
> > news:1166619985.208731.246740@a3g2000cwd.googlegroups.com...
> > > hello,
> > > i am writting a network driver,and facing problem in ICMP resolve.
> > > can anybody tell me how to form a proper packet in receive path.?
> > > it is a miniport - ndis driver.
> > >
> > > first i am creating a packet,
> > > NdisAllocateBuffer();
> > > NdisAllocatePacket();
> > > I copied the ICMP packet of 98 bytes,,
> > > then set the status of the packet to NDIS_SET_PACKET_STATUS(
> > > packet,,_SUCCESS)
> > > then attached the packet at front,
> > > and then send it to upper layer ,,,
> > > NdisMIndicateReceive();
> > >
> > > Am i missing something? if yes then tell me how to resolve it,?
> > >
> > > thanks,,
> > > from
> > > Hitesh
> > >
>

Stephan
Thu Dec 21 11:09:08 CST 2006

hitesh wrote:
> i am not creating packet every time and deleting but,
> at starting i have created a packet and after that i am using the same
> packet for all allocated buffers.

So do you see the ICMP packet in Ethereal or not?

I suggest you run the NDISTest tool against your miniport. It generates
a lot of debug output if that will help you understand what's wrong.
See

"Testing Network Drivers with the NDIS Test Tool"
http://www.wd-3.com/archive/NDISTest.htm

"Using NDISTest During Driver Development"
http://www.microsoft.com/whdc/DevTools/tools/NDIStest.mspx

Stephan

hitesh
Thu Dec 21 21:15:42 CST 2006

Thanks for reply,
Yes, i can.
i am able to see packet on Ethereal, in both the cases which i mention
in previous mail.
Also i am setting mac header to 14 bytes everytime.
i dont know where is something going wrong,?
thanks
From
Hitesh

Stephan Wolf [MVP] wrote:
> hitesh wrote:
> > i am not creating packet every time and deleting but,
> > at starting i have created a packet and after that i am using the same
> > packet for all allocated buffers.
>
> So do you see the ICMP packet in Ethereal or not?
>
> I suggest you run the NDISTest tool against your miniport. It generates
> a lot of debug output if that will help you understand what's wrong.
> See
>
> "Testing Network Drivers with the NDIS Test Tool"
> http://www.wd-3.com/archive/NDISTest.htm
>
> "Using NDISTest During Driver Development"
> http://www.microsoft.com/whdc/DevTools/tools/NDIStest.mspx
>
> Stephan

Stephan
Fri Dec 22 09:45:00 CST 2006

Also try the "netstat -s" command and check the IP and ICMP statistics.

Also make sure the ARP entries showed by "arp -a" make sense. Try a
"arp -d *" before the ping.

Stephan

hitesh
Thu Jan 11 05:19:43 CST 2007

hello stephan,
thanks for the reply,

today i found a strange problem,
actually there is a problem in the ICMP request/ reply.

it is like this,
whenever any packet comes to the hardware layer there is a wrong FCS
(CRC)( the last field of the ICMP packet ), it is corrupted.
i dont know what could be the problem?
is there any different algorithem for calcaulating FCS in linux and
windows?
also i found that the ICMP packet contains data like
abcdefghijkl,,,,,xyz and some sequencial numbers,,,,?
is it correct data?

please reply me,
thanks,
from
Hitesh Ughreja.

Stephan Wolf [MVP] wrote:
> Also try the "netstat -s" command and check the IP and ICMP statistics.
>
> Also make sure the ARP entries showed by "arp -a" make sense. Try a
> "arp -d *" before the ping.
>
> Stephan

Thomas
Thu Jan 11 10:19:15 CST 2007

I don't know what kind of miniport that you are working with, but for
Ethernet the operating system never sees the FCS. On receive it is checked
by the receiving hardware and only good packets are passed up to the
operating system. The FCS is _NOT_ included in the packet passed to
protocols bound to the adapter.

On send the FCS is generated by the adapter hardware when the packet is
sent.

Understand that there is a minimum packet size. Packets that are smaller
than the minimum are "padded" with extra bytes to insure that this minimum
is sent.

A ICMP ping request typically includes a payload of some information. Often
the payload is something like "abcdef...". This page includes a quick
illustration of a ping packet received by a Windows machine:

http://ndis.com/papers/ndispacket/ndispacket1.htm

Thomas F. Divine

"hitesh" <hitesh.ughreja@gmail.com> wrote in message
news:1168514383.589742.304520@k58g2000hse.googlegroups.com...
> hello stephan,
> thanks for the reply,
>
> today i found a strange problem,
> actually there is a problem in the ICMP request/ reply.
>
> it is like this,
> whenever any packet comes to the hardware layer there is a wrong FCS
> (CRC)( the last field of the ICMP packet ), it is corrupted.
> i dont know what could be the problem?
> is there any different algorithem for calcaulating FCS in linux and
> windows?
> also i found that the ICMP packet contains data like
> abcdefghijkl,,,,,xyz and some sequencial numbers,,,,?
> is it correct data?
>
> please reply me,
> thanks,
> from
> Hitesh Ughreja.
>
> Stephan Wolf [MVP] wrote:
>> Also try the "netstat -s" command and check the IP and ICMP statistics.
>>
>> Also make sure the ARP entries showed by "arp -a" make sense. Try a
>> "arp -d *" before the ping.
>>
>> Stephan
>

Maxim
Thu Jan 11 16:36:04 CST 2007

Windows software does not touch FCS. FCSs are the job of the NIC hardware.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"hitesh" <hitesh.ughreja@gmail.com> wrote in message
news:1168514383.589742.304520@k58g2000hse.googlegroups.com...
> hello stephan,
> thanks for the reply,
>
> today i found a strange problem,
> actually there is a problem in the ICMP request/ reply.
>
> it is like this,
> whenever any packet comes to the hardware layer there is a wrong FCS
> (CRC)( the last field of the ICMP packet ), it is corrupted.
> i dont know what could be the problem?
> is there any different algorithem for calcaulating FCS in linux and
> windows?
> also i found that the ICMP packet contains data like
> abcdefghijkl,,,,,xyz and some sequencial numbers,,,,?
> is it correct data?
>
> please reply me,
> thanks,
> from
> Hitesh Ughreja.
>
> Stephan Wolf [MVP] wrote:
> > Also try the "netstat -s" command and check the IP and ICMP statistics.
> >
> > Also make sure the ARP entries showed by "arp -a" make sense. Try a
> > "arp -d *" before the ping.
> >
> > Stephan
>