NDIS PIM driver

OSR_Community_User · September 25, 2001, 11:16am

I’ve done this method to interceipt packets. Everything is Ok, but when I
try to use
local net some problems arise. For example if I download a file from local
net, it doesn’t want
to complete downloading… Though, after killing downloading process the
downloaded file is falid.

So, what can it be ?

P.S. I’m interceipting NdisSend and ProtocolReceive functions only.

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

Michal_Vodicka-1 · September 25, 2001, 3:11pm

It is w9x question, right? Well, I have such a driver and there is no
problem. Try to start with empty handlers and don’t alter anything, just
call original function. I don’t believe it is possible to have working
driver which intercepts only mentioned two functions but I may be wrong, it
is long time ago I wrote it…

BTW, Thomas Divine has a working example to sell.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]

From: jenson[SMTP:xxxxx@beep.ru]
Reply To: NT Developers Interest List
Sent: Tuesday, September 25, 2001 5:13 PM
To: NT Developers Interest List
Subject: [ntdev] NDIS PIM driver

I’ve done this method to interceipt packets. Everything is Ok, but when I
try to use
local net some problems arise. For example if I download a file from local
net, it doesn’t want
to complete downloading… Though, after killing downloading process the
downloaded file is falid.

So, what can it be ?

P.S. I’m interceipting NdisSend and ProtocolReceive functions only.

You are currently subscribed to ntdev as: xxxxx@rkk.cz
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

OSR_Community_User · September 26, 2001, 3:34am

Yes, it is …
Why do you think it’s impossible ? I need nothing more than packets …
Other handlers
are implemented by system (winsock I guess …) So why not ?
Actually the problem is in ProtocolReceive only I guess, because when I
switch off ProtocolReceive Interceiption everything works fine.
To be more precise, My driver does the following :

get a packet (indicated)
Saves it somewhere
shows it up a bit later.

Should I implement ProtocolReceiveComplete in this case ? Or
system-implemented handlers are ok ?
Maybe I should implement some other handlers, shouldn’t I ?

I know about the sample… but … would you lend me 500$ ? :))))

It is w9x question, right? Well, I have such a driver and there is no
problem. Try to start with empty handlers and don’t alter anything, just
call original function. I don’t believe it is possible to have working
driver which intercepts only mentioned two functions but I may be wrong,
it
is long time ago I wrote it…

BTW, Thomas Divine has a working example to sell.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.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

Michal_Vodicka-1 · September 26, 2001, 3:15pm

> ----------

From: jenson[SMTP:xxxxx@beep.ru]
Reply To: NT Developers Interest List
Sent: Wednesday, September 26, 2001 9:31 AM
To: NT Developers Interest List
Subject: [ntdev] RE: NDIS PIM driver

Yes, it is …
Why do you think it’s impossible ? I need nothing more than packets …
Other handlers
are implemented by system (winsock I guess …) So why not ?

Winsock?! Maybe you should read NDIS docs and try to understand how things
work (sorry, no offence). What you (probably) want to write is something
similar to NDIS IM driver and you should use similar approach. All depends
on what do you want to do. For example, if you want change packet size, you
have to inform above driver (tcpip?) about different maximal size and it is
necessary to hook request handler. Also, you should be informed about
opening and closing adapter, you can’t indicate packet receive after adapter
is closed (and related structures freed) and so on.

Actually the problem is in ProtocolReceive only I guess, because when I
switch off ProtocolReceive Interceiption everything works fine.
To be more precise, My driver does the following :

get a packet (indicated)

Saves it somewhere

shows it up a bit later.

What does mean “a bit later”? Do you indicate it in original ProtocolReceive
context? Do you indicate full packets?

Should I implement ProtocolReceiveComplete in this case ? Or
system-implemented handlers are ok ?

It may be your problem. Protocols shouldn’t process packet in
ProtocolReceive handler, only store it and process it later in
ReceiveComplete handler. So if you don’t hook this one, you change expected
call order and cause problems. You should at least indicate receive complete
manually after you indicate packet.

Maybe I should implement some other handlers, shouldn’t I ?

See above.

I know about the sample… but … would you lend me 500$ ? :))))

It depends how much costs your time. It would probably save you several
weeks or months of trial-error work. We bought an initial version of this
example (somewhat cheaper), I examined it and wrote my driver from scratch
looking to example code. As a result I had a working driver quickly and
could avoid subtle problems with hideous w9x “system”.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.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

OSR_Community_User · September 27, 2001, 3:26am

No no no … It was a mistake … of course it’s “tcpip” …
sorry

Winsock?! Maybe you should read NDIS docs and try to understand how things
work (sorry, no offence). What you (probably) want to write is something
similar to NDIS IM driver and you should use similar approach. All depends
on what do you want to do. For example, if you want change packet size,
you
have to inform above driver (tcpip?) about different maximal size and it
is
necessary to hook request handler. Also, you should be informed about
opening and closing adapter, you can’t indicate packet receive after
adapter
is closed (and related structures freed) and so on.

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

OSR_Community_User · September 28, 2001, 11:02am

I mean, I indicate them in a different thread, I create for this purpose…
Packets are full, I mean that PacketSize == LookAheadBufferSize
I save original buffers, and then Indicate packet using them.

What does mean “a bit later”? Do you indicate it in original
ProtocolReceive
context? Do you indicate full packets?

Ok ! So, if what should I do, If I want to block a Packet ? I think it’s
impossible to block it without
processing it !
Ok, I may process packet very quickly … Should I understand your word like
“it’s impossible to delay indicated packet for a time ?”

It may be your problem. Protocols shouldn’t process packet in
ProtocolReceive handler, only store it and process it later in
ReceiveComplete handler. So if you don’t hook this one, you change
expected
call order and cause problems. You should at least indicate receive
complete
manually after you indicate packet.

You are currently subscribed to ntdev as: xxxxx@beep.ru
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

Thomas_F_Divine · September 28, 2001, 11:30am

----- Original Message -----
From: “jenson”
To: “NT Developers Interest List”
Sent: Friday, September 28, 2001 10:45 AM
Subject: [ntdev] RE: NDIS PIM driver

> I mean, I indicate them in a different thread, I create for this
purpose…
> Packets are full, I mean that PacketSize == LookAheadBufferSize
> I save original buffers, and then Indicate packet using them.
>
> > What does mean “a bit later”? Do you indicate it in original
> ProtocolReceive
> > context? Do you indicate full packets?
>
> Ok ! So, if what should I do, If I want to block a Packet ? I think it’s
> impossible to block it without
> processing it !

That depends on how complex your decision making is. Protocol’s (and the
lower-edge of NDIS IM’s and filters) almost always take a “quick look” at
received packets in their receive handler; a programmer makes a judgement as
to which is most efficient: 1.) quick look at data or 2.) make copy and look
later.

For example, TCP/IP would not accept non-TCP/IP packets by checking (in the
receive handler) a few fields in the LookAhead data. That’s what LookAhead
data is for; to make quick decisions about whether to accept each packet or
not.

If your decision to block a packet is simple enough, then you do not have to
make copy of packet, etc. Instead, quickly examine the original packet and
make the decision.

To block a send, simply tell the sender that the packet was sent (send
complete) but do not actually send it.
To block a receive, simply do not call the protocol’s receive handler.

Michael’s comment about “not processing packets in the receive handler” is
certainly correct if “processing” requires much more then a few quick peeks
into LookAhead data. For example, if you were going to decrypt or decompress
packets (which might take a lot of time), then you certainly wouldn’t do it
in a ReceiveHandler.

If your idea of “block” is actually to “delay” a packet for a programmable
period of time (like PCAUSA’s IP Link Characteristics Emulator), then you do
have to make complete copies of the packets that are being delayed, queue
them, examine the queues in a timer and pass the packets on their way when
it is their time.

Regards,

Thomas F. Divine

PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - NDIS Intermediate - TDI Client
http: - http:

—
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</http:></http:>

OSR_Community_User · September 28, 2001, 11:47am

In what cases packet is accepted ? In the case when the packet is a
TCP-packet, right ? and in all other
cases the packet is rejected, isnt it ? May I check it by myself and
indicate only TCP packets (I mean will the system work in this case ? )?

For example, TCP/IP would not accept non-TCP/IP packets by checking (in
the
receive handler) a few fields in the LookAhead data. That’s what LookAhead
data is for; to make quick decisions about whether to accept each packet
or
not.

So what is the scheme, if “delays” are long ?

make a copy
reject original
receive my own-reconstructed packet ?

ProtocolReceive returnes NDIS_STATUS
if i want to delay the packet, I dont Indicate Packet, and dont get Status
to be returned…
So What value should I return then ???

Michael’s comment about “not processing packets in the receive handler” is
certainly correct if “processing” requires much more then a few quick
peeks
into LookAhead data. For example, if you were going to decrypt or
decompress
packets (which might take a lot of time), then you certainly wouldn’t do
it
in a ReceiveHandler.

If your idea of “block” is actually to “delay” a packet for a programmable
period of time (like PCAUSA’s IP Link Characteristics Emulator), then you
do
have to make complete copies of the packets that are being delayed, queue
them, examine the queues in a timer and pass the packets on their way when
it is their time.

Regards,

Thomas F. Divine

PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - NDIS Intermediate - TDI Client
http: - http:
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@beep.ru
> 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</http:></http:>

Thomas_F_Divine · September 28, 2001, 12:11pm

----- Original Message -----
From: “jenson”
To: “NT Developers Interest List”
Sent: Friday, September 28, 2001 11:30 AM
Subject: [ntdev] RE: NDIS PIM driver

> In what cases packet is accepted ?

I would think that is your decision…

>In the case when the packet is a
> TCP-packet, right ? and in all other
> cases the packet is rejected, isnt it ? May I check it by myself and
> indicate only TCP packets (I mean will the system work in this case ?
) )?
>

You can probably check yourself. After all, your simple PIM driver is
probably in the MSTCP binding only.

> > For example, TCP/IP would not accept non-TCP/IP packets by checking (in
> the
> > receive handler) a few fields in the LookAhead data. That’s what
LookAhead
> > data is for; to make quick decisions about whether to accept each packet
> or
> > not.
> >
> So what is the scheme, if “delays” are long ?
> 1. make a copy
> 2. reject original
> 3. receive my own-reconstructed packet ?
>
> ProtocolReceive returnes NDIS_STATUS
> if i want to delay the packet, I dont Indicate Packet, and dont get Status
> to be returned…
> So What value should I return then ???

Your PIM filter should accept any packet that you want to copy and
eventually pass upwards to TCP/IP. At that point it is your PIM driver that
is accepting the packet.

Later, when you call MSTCP’s ProtocolReceive handler with your copy of a
packet (or just the packet data) MSTCP will make it’s own decision and tell
you whether or not it accepted your packet.

You need to study NDIS more. For example, if you study how NDIS protocols
work you will learn how to work with NDIS drivers that are “above” your
filter. If you study how NDIS miniports work, then you will learn how to
work with NDIS drivers that are “below” your filter.

I hope you are not in a hurry…

Good luck,

Thomas F. Divine

PCAUSA - Toolkits & Resources For Network Software Developers
NDIS Protocol - NDIS Intermediate - TDI Client
http: - http:

—
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</http:></http:>

Michal_Vodicka-1 · September 28, 2001, 2:20pm

> ----------

From: jenson[SMTP:xxxxx@beep.ru]
Reply To: NT Developers Interest List
Sent: Friday, September 28, 2001 4:45 PM
To: NT Developers Interest List
Subject: [ntdev] RE: NDIS PIM driver

I mean, I indicate them in a different thread, I create for this
purpose…
Packets are full, I mean that PacketSize == LookAheadBufferSize
I save original buffers, and then Indicate packet using them.

OK, just for clarity: do you copy original buffers contents or just save
passed pointers? The second is wrong because pointers are valid only in
ProtocolReceive context.

> What does mean “a bit later”? Do you indicate it in original
ProtocolReceive
> context? Do you indicate full packets?

Ok ! So, if what should I do, If I want to block a Packet ? I think it’s
impossible to block it without
processing it !

As Thomas wrote, make quick decision in receive handler and copy packet if
needs more processing later. The reason for quick decision is packet
processing in MAC driver. I’m not quite sure about w9x but on NT
ProtocolReceive handler is called at DISPATCH_LEVEL which blocks next packet
processing on the same CPU in the MAC driver. If your handler is too slow,
some packets can be lost. On the other hand for testing purposes I tried to
make relatively slow packet decryption in the receive handler and haven’t
see a problem on 100 MBit network. Packets weren’t lost and performance was
comparable with processing in the receive complete handler. But it isn’t a
good idea, it may depend on current hardware (buffers), MAC driver and CPU
speed.

Ok, I may process packet very quickly … Should I understand your word
like
“it’s impossible to delay indicated packet for a time ?”

No, it is of course possible but you have to understand how NDIS works and
don’t change packet ordering. Also, if delays are too long, it can cause TCP
stack problems.

Follow Thomas’s recomendation and study NDIS more. It is rather complex and
it isn’t so easy to hook it and do someting with packets. Much more complex
than for example DOS packet drivers. I believe that a good PIM driver should
be very similar to NDIS IM drivers. The only difference is the way how you
hook into NDIS.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.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