I need to do raw ethernet packets, and looked at the Packet example in
the DDK.
Everything seems to work fine, but here are my questions:
- Is it possible to modify this device driver to only accept packets based
on some predetermined values in some of the header fields (e.g.
the protocol type field would have a value other than 0X0800).
One option I know is to have the application can do some filtering,
but it would be nice if the driver can do that filtering, such that other
packets wont even cause the read or receive to return.
- If possible, where is the best place to put my changes in (I am looking
at the read.c file and dont really know where the correct place is to
reject packets and still keep the pending reads etc).
Thanks,
----- Original Message -----
From: Satrio Mualim
To: NT Developers Interest List
Sent: Monday, November 27, 2000 12:00 PM
Subject: [ntdev] Newwbie: Packet driver Question
>
> I need to do raw ethernet packets, and looked at the Packet example in
> the DDK.
> Everything seems to work fine, but here are my questions:
> 1. Is it possible to modify this device driver to only accept packets
based
> on some predetermined values in some of the header fields (e.g.
> the protocol type field would have a value other than 0X0800).
> One option I know is to have the application can do some filtering,
> but it would be nice if the driver can do that filtering, such that
other
> packets wont even cause the read or receive to return.
> 2. If possible, where is the best place to put my changes in (I am looking
> at the read.c file and dont really know where the correct place is to
> reject packets and still keep the pending reads etc).
> Thanks,
>
Yes, that is certainly possible and desirable.
There are two places that you must check the protocol type:
PacketReceivePacket - The most common entry point on Windows 2000.
PacketReceiveIndicate - Less commonly called, but required, on Windows 2000.
Almost always called on other platforms. Easy to filter here. The MAC
header, with Type/Length, is in the HeaderBuffer. The LookaheadBuffer starts
the IP Header.
PCAUSA has an unfinished (sorry) note about interpreting and building NDIS
packets. The UTIL_ReadOnPacket code fragment (link at bottom of page) is
useful in fetching info from an arbitrary NDIS packet.
See URL:
http:
Good luck,
Thomas F. Divine
PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - TDI Client - Windows 95 Redirector
http:</http:></http:>
“Thomas F. Divine” wrote:
PacketReceivePacket - The most common entry point on Windows 2000.
PacketReceiveIndicate - Less commonly called, but required, on Windows 2000.
Almost always called on other platforms. Easy to filter here. The MAC
header, with Type/Length, is in the HeaderBuffer. The LookaheadBuffer starts
the IP Header.
Thanks for the very useful info.
Just one follow up question, if the code is intended to run on NT 4 only, is it
sufficient to do the filtering in “PacketReceiveIndicate” only or do I still
need to
modify the “PacketReceivePacket” routine as well?
Thanks
----- Original Message -----
From: Satrio Mualim
To: NT Developers Interest List
Sent: Wednesday, November 29, 2000 10:10 AM
Subject: [ntdev] Re: Newwbie: Packet driver Question
>
> “Thomas F. Divine” wrote:
>
> > PacketReceivePacket - The most common entry point on Windows 2000.
> >
> > PacketReceiveIndicate - Less commonly called, but required, on Windows
2000.
> > Almost always called on other platforms. Easy to filter here. The MAC
> > header, with Type/Length, is in the HeaderBuffer. The LookaheadBuffer
starts
> > the IP Header.
>
> Thanks for the very useful info.
> Just one follow up question, if the code is intended to run on NT 4 only,
is it
> sufficient to do the filtering in “PacketReceiveIndicate” only or do I
still
> need to
> modify the “PacketReceivePacket” routine as well?
I personally have not seen the PacketReceivePacket entry point called on
Windows NT. However, the NDIS spec suggests it could be.
There is a note on this topic at on the NDIS GAQ at:
http:
The specific PCAUSA Knowledge Base Atricle is at:
http:
Good luck,
Thomas F. Divine
PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - TDI Client - Windows 95 Redirector
http: - http:</http:></http:></http:></http:>
“Thomas F. Divine” wrote:
I personally have not seen the PacketReceivePacket entry point called on
Windows NT. However, the NDIS spec suggests it could be.
Thanks again for the very informative answers.
Looking at the “packet” driver code, what are the limitations of this particular
example?
In particular, would it support binding and sending to 2 network interface
cards?
How about more than one application using this driver?
If not, in general terms, what is needed to make it satisfy the two questions
above?
Thanks,
----- Original Message -----
From: Satrio Mualim
To: NT Developers Interest List
Sent: Wednesday, December 06, 2000 10:00 AM
Subject: [ntdev] Re: Newwbie: Packet driver Question
>
>
> “Thomas F. Divine” wrote:
>
> > I personally have not seen the PacketReceivePacket entry point called on
> > Windows NT. However, the NDIS spec suggests it could be.
>
> Thanks again for the very informative answers.
> Looking at the “packet” driver code, what are the limitations of this
particular
> example?
It is a fine basic example of a NDIS protocol driver.
> In particular, would it support binding and sending to 2 network interface
> cards?
I have not used it, so I cannot say with authority. However, there is no
doubt that it could be adapted to operate on multiple NICs concurrently.
> How about more than one application using this driver?
That also is certainly possible. Depending on your requirements, you may
need to provide mechanisms to distinguish between different handles opened
from Win32 and any associations you may desire to make between the handles
and the NICs. That’s in your court. For example, you might want a write on
any handle to send packets on all bound NICs, or only one specific one.
> If not, in general terms, what is needed to make it satisfy the two
questions
> above?
AFAIK all you need is to apply standard Windows NT device driver programing
techniques to extend the sample as you desire.
> Thanks,
Hope this helps.
Regards,
Thomas F. Divine
PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - NDIS Intermediate - TDI Client
http: - http:</http:></http:>