Hello Everyone
Im trying to understand what exactly that I can do with a protocol driver that I cant with a LWF driver !
and If an application in my system sent a packet , does that mean the LWF and the protocol driver I made both will receive it ? can I modify it in the protocol driver like I do in the LWF ?
Sorry but im still totally lost, I read many articles and no one actually yet gave the Big pictures of the NDIS stack
Thank you in advance
The figure at this URL offers some help:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff565492(v=vs.85).a
spx
Except the block at the top doesn’t represent just 0ne NDIS protocol driver.
Instead it represents all top-level NDIS protocol drivers. This would
include the Microsoft TCP/IP protocol driver and any other NDIS protocol
drivers.
At the top ALL NDIS protocol drivers can receive ALL packets indicated
upwards from the highest filter in the stack of layered over the
lowest-level miniport adapter. More specifically: There is nothing one NDIS
protocol driver can do to prevent another peer NDIS protocol driver from
receiving a packet.
Filter drivers lie between the top-level NDIS protocol drivers and the
lower-level NDIS filters and the NDIS miniports (at the bottom). Modifying
NDIS filters can, well, “filter” packets. They can block received packets or
inject their own.
Hope this helps.
Thomas F. Divine
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, February 13, 2014 3:03 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Protocol drivers vs LWF
Hello Everyone
Im trying to understand what exactly that I can do with a protocol driver
that I cant with a LWF driver !
and If an application in my system sent a packet , does that mean the LWF
and the protocol driver I made both will receive it ? can I modify it in the
protocol driver like I do in the LWF ?
Sorry but im still totally lost, I read many articles and no one actually
yet gave the Big pictures of the NDIS stack
Thank you in advance
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thank you very much Thomas
So I can say Protocol Drivers can only read packets and monitor them but they cant actually modify or block them to go down through the Stack, while Filter drivers below can intercept, monitor, modify the packets, Block them and replicate their new version of the packet down toward the lower filters and miniport.
Thus filter drivers could be more general use than protocol drivers !?
Why do anyone need to make a new protocol Driver while the tcp/ip protocol provided maybe enough doing the job done ?
Sorry for my basic questions but well 
Best Regards,
> Thus filter drivers could be more general use than protocol drivers !?
Once in NDIS 5 (if not NDIS 4) the IM (filter) was a combination of a protocol and a miniport in a single binary.
Actually, code-wise, MUX IM (lack of 1-to-1 relation of virtual adapters on top to adapters below) was really a miniport+a protocol, with 1 and only 1 call which was filter-specific.
Filter IM (mandated 1-to-1) was a bit simpler and different, not only in the code, but also in the install INF.
Protocol is the entity which can send packets and listen to them. Nothing else. Any kmode binary can have NDIS protocol lower edge.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
There are a variety of reasons why one might want a proprietary NDIS
protocol driver.
Use of industrial protocols other than TCP/IP being just one. Monitoring of
actual network packets being another.
These days (Vista+) it is better to consider using the Windows Filtering
Platform (WFP) and NDIS filter drivers over NDIS protocol driver. Of course,
it depends entirely on what you really need to accomplish.
Good luck,
Thomas F. Divine
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, February 13, 2014 10:17 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Protocol drivers vs LWF
Thank you very much Thomas
So I can say Protocol Drivers can only read packets and monitor them but
they cant actually modify or block them to go down through the Stack, while
Filter drivers below can intercept, monitor, modify the packets, Block them
and replicate their new version of the packet down toward the lower filters
and miniport.
Thus filter drivers could be more general use than protocol drivers !?
Why do anyone need to make a new protocol Driver while the tcp/ip protocol
provided maybe enough doing the job done ?
Sorry for my basic questions but well
Best Regards,
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> Why do anyone need to make a new protocol Driver while the tcp/ip protocol provided maybe enough doing the job done ?
Because the whole world isn’t TCP/IP.
– Bob Ammerman
RAm Systems
Very good info now i could sum things up as per my baby steps
Protocol Drivers:
That is pretty clear to me now
Now the Final Question (i promise …) :
Im studying the samples with WDK and i will try to figure out from your response which code is which responsible for the roadmap . I google the whole day to clarify things for myself and unfortunately books are very rare with such details as we need them.
Thank you very much again .
All protocols will receive the IPX packet.
Only protocols designed to recognize and process IPX packets will perform
any work on the received packet. This assumes your IPX is not tunneled via
IP.
Good luck!
Thomas F. Divine
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, February 13, 2014 11:16 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Protocol drivers vs LWF
Very good info now i could sum things up as per my baby steps
Protocol Drivers:
That is pretty clear to me now
Now the Final Question (i promise …) :
Im studying the samples with WDK and i will try to figure out from your
response which code is which responsible for the roadmap . I google the
whole day to clarify things for myself and unfortunately books are very rare
with such details as we need them.
Thank you very much again .
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>protocols will Pass down the packet received and the IPX protocol is the only one that will intercept
and redirect it to the proper application via NDIS port engine . is that what happens in general ?
Yes. Other protocols will see the packet and refuse to handle it after the smallest possible amount of work.
- Also if I made a user-mode application and I bound it to the TCP/IP protocol
What do you mean as “bound the user app to TCP/IP”? Bound by what means?
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
>What do you mean as “bound the user app to TCP/IP”? Bound by what means?
I meant bound to a specific Device with a specific protocol that have that protocol supported and installed on it :
CHAR NdisProtDevice = “\\.\\NdisProt”; // the protocol driver name on the device
Handle = CreateFileA(
NdisProtDevice,
DesiredAccess,
ShareMode,
lpSecurityAttributes,
CreationDistribution,
FlagsAndAttributes,
NULL
);
wNdisDeviceName = the Full GUID of the NIC
(DeviceIoControl(
Handle, // handle to the protocol
IOCTL_NDISPROT_OPEN_DEVICE,
(LPVOID)&wNdisDeviceName[0], // the Device name
wNameLength*sizeof(WCHAR),
NULL,
0,
&BytesReturned,
NULL));
So from the user mode I can bind my IO calls to that device with a handle to my protocol, that what I understood up to now from the NdisProto Example from the WDK .
is that correct ?
>2. Also if I made a user-mode application and I bound it to the TCP/IP protocol not any other >proprietary protocol but the original TCP/IP , that is going to be exactly like making a Winsock >Application and bind it with the IP_PROTO .!?
Yes, but a communication interface would be different. You would need to communicate through standard user application - Windows driver communication. You could use Read, Write or IOCTL requests.
> Yes, but a communication interface would be different. You would need to
communicate through standard user application - Windows driver communication.
You could use Read, Write or IOCTL requests.
Great information that will put me on the way to proceed .
Thank you very much Igor, Maxim, bob and Thomas