Passthru

NTDEV
1

I am using Passthru on 2k. I want to log packet data into a file.
Whenever the driver gets the packet (say in SendPacket) it signals a
Logger Service which in turn sends a DeviceIOControl and fetches the data.
But I think all this is slow, because I am not able to log some packets.

Is there any other way to do this ? OR Can the above method be enhanced to
get all the packets.

2

> Whenever the driver gets the packet (say in SendPacket) it signals a

Logger Service which in turn sends a DeviceIOControl and fetches the
data.
But I think all this is slow, because I am not able to log some
packets.

Is there any other way to do this ? OR Can the above method be
enhanced to
get all the packets.

Yes. This is the correct way. Just copy the packet data to another
memory chunk and deliver this another memory chunk to inverse call
engine to be fetched by the app’s IOCTL.

Max

3

For starters, drop the service, at least for effecting the logging. Do
the work in a kernel thread, to avoid the need for IOCTLs and state
switch.

Next, make a copy and point to it in a work request that your IM driver
queues up.

Third, have the kernel-thread routine run on a timer. The routine sets a
bit in kernel storage when it becomes active and turns off the bit when
it is going inactive. It’s probably good for the routine to run at
DISPATCH_LEVEL when working, to minimize time lost to other work and to
interruptions. The routine adjusts wait interval depending on recent
activity.

Fourth, have the IM driver queue up the work and then check the bit: If
it is on, the work will be (or is being or has been done). If the bit is
off, the work may have been done, but since that cannot be cheaply
ascertained, signal the kernel-thread routine.

The above is only a sketch for a server kernel-thread routine. Be
careful in a proper design to take race conditions into account. Note
further that even in the best case (on a multiple-CPU system anyway,
even with the kernel-thread routine doing work at DISPATCH_LEVEL), a
design with a fixed (versus extendable) buffer size can result in
packets not logged due to the buffer being full.

–
If replying by e-mail, please remove “nospam.” from the address.

James Antognini
Windows DDK MVP

4

For the DISPATCH_LEVEL part: Stupid idea. How’s the routine going to do
I/O with it on?

–
If replying by e-mail, please remove “nospam.” from the address.

James Antognini
Windows DDK MVP

5

It is possible, even likely, to drop packets if you they are not
serviced fast enough. Accordingly, you should do as much of this work
in Kernel space as possible. At least, minimize the number of Kernel
mode/User mode transitions by always having a buffer waiting in Kernel
space (pended read) – instead of signaling when a buffer is ready –
and perhaps use a larger buffer to return several packets at once.

Bryan S. Burgin
xxxxx@microsoft.com

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Abhijit Kulkarni
Sent: Tuesday, July 15, 2003 5:36 AM
To: Windows System Software Developers Interest List
Subject: [ntdev] Passthru

I am using Passthru on 2k. I want to log packet data into a file.
Whenever the driver gets the packet (say in SendPacket) it signals a
Logger Service which in turn sends a DeviceIOControl and fetches the
data.
But I think all this is slow, because I am not able to log some packets.

Is there any other way to do this ? OR Can the above method be enhanced
to
get all the packets.

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

I would use everything at once: several pended IRPs every one with a large
buffer. When an IRP returns, user mode app should immediatelly send a new
one to kernel. Buffer size and necessary IRP number depends on network and
CPU speed, some testing is necessary.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From: xxxxx@microsoft.com[SMTP:xxxxx@microsoft.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, July 15, 2003 7:09 PM
To: xxxxx@lists.osr.com
Cc: xxxxx@yahoo.com
Subject: [ntdev] RE: Passthru

It is possible, even likely, to drop packets if you they are not
serviced fast enough. Accordingly, you should do as much of this work
in Kernel space as possible. At least, minimize the number of Kernel
mode/User mode transitions by always having a buffer waiting in Kernel
space (pended read) – instead of signaling when a buffer is ready –
and perhaps use a larger buffer to return several packets at once.

Bryan S. Burgin
xxxxx@microsoft.com

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Abhijit Kulkarni
Sent: Tuesday, July 15, 2003 5:36 AM
To: Windows System Software Developers Interest List
Subject: [ntdev] Passthru

I am using Passthru on 2k. I want to log packet data into a file.
Whenever the driver gets the packet (say in SendPacket) it signals a
Logger Service which in turn sends a DeviceIOControl and fetches the
data.
But I think all this is slow, because I am not able to log some packets.

Is there any other way to do this ? OR Can the above method be enhanced
to
get all the packets.

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to ntdev as: michal.vodicka@st.com
To unsubscribe send a blank email to xxxxx@lists.osr.com