Serial Filter Driver

NTDEV
1

Hi,

I want do develop a filter driver for a bluetooth device that registers
itself as a COM port. If a software opens a handle to the device and
sets parameters like baud rate the driver should block this and instead
send a specified string to the device. Now i have this filter sample
from the toaster directory and don’t really know how I should realize
this. Can anyone tell me (in theory) what i have to do to achieve this
functionality? I don’t know from which event i have to open a queue and
how to access the data in the incoming IRP. I think it must be
IPR_MJ_CREATE and IRP_MJ_DEVICE_CONTROL (Serial Device Controle
Request?), right?

Thank you in advance.
Hannes

2

Hannes,

Do you want the device to look like a serial port to the OS or do you want
the device to look like a Bluetooth radio? (or perhaps it is a serial
attached radio device that pairs with a SPP device you want to look like a
serial port to the OS?)

Is the device actually a serial port integrated into the system or does it
attach to a real/generic serial port and enumerate via SerEnum?

If you can do a more complete job of describing the actual hardware
attachment and enumerated driver stack it would be easier to suggest how you
might accomplish your goal.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hannes Finck
Sent: Thursday, November 06, 2008 9:58 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Serial Filter Driver

Hi,

I want do develop a filter driver for a bluetooth device that registers
itself as a COM port. If a software opens a handle to the device and
sets parameters like baud rate the driver should block this and instead
send a specified string to the device. Now i have this filter sample
from the toaster directory and don’t really know how I should realize
this. Can anyone tell me (in theory) what i have to do to achieve this
functionality? I don’t know from which event i have to open a queue and
how to access the data in the incoming IRP. I think it must be
IPR_MJ_CREATE and IRP_MJ_DEVICE_CONTROL (Serial Device Controle
Request?), right?

Thank you in advance.
Hannes

NTDEV is sponsored by OSR

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

3

Hi David,

The bluetooth device already looks like a COM port to the system. It
offers a virtual COM port, software can communicate with. I want a
filter driver that can manipulate data coming from the usermode software
and going to the virtual COM port. I don’t know if this might help you,
but the device shows up under the COM port section in FilterMan. It is
enumerated by BTHENUM (Service: BTHMODEM). I don’t exactly know where
the filter must hook in. Till now i thaught this must be PORTS, because
this shown there, too.

Sorry for the incomplete description, this is my first attempt of
developing a driver.

Regards
Hannes

David R. Cattley schrieb:

Hannes,

Do you want the device to look like a serial port to the OS or do you want
the device to look like a Bluetooth radio? (or perhaps it is a serial
attached radio device that pairs with a SPP device you want to look like a
serial port to the OS?)

Is the device actually a serial port integrated into the system or does it
attach to a real/generic serial port and enumerate via SerEnum?

If you can do a more complete job of describing the actual hardware
attachment and enumerated driver stack it would be easier to suggest how you
might accomplish your goal.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hannes Finck
Sent: Thursday, November 06, 2008 9:58 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Serial Filter Driver

Hi,

I want do develop a filter driver for a bluetooth device that registers
itself as a COM port. If a software opens a handle to the device and
sets parameters like baud rate the driver should block this and instead
send a specified string to the device. Now i have this filter sample
from the toaster directory and don’t really know how I should realize
this. Can anyone tell me (in theory) what i have to do to achieve this
functionality? I don’t know from which event i have to open a queue and
how to access the data in the incoming IRP. I think it must be
IPR_MJ_CREATE and IRP_MJ_DEVICE_CONTROL (Serial Device Controle
Request?), right?

Thank you in advance.
Hannes

NTDEV is sponsored by OSR

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

4

Hannes Finck wrote:

The bluetooth device already looks like a COM port to the system. It
offers a virtual COM port, software can communicate with. I want a
filter driver that can manipulate data coming from the usermode
software and going to the virtual COM port. I don’t know if this might
help you, but the device shows up under the COM port section in
FilterMan. It is enumerated by BTHENUM (Service: BTHMODEM). I don’t
exactly know where the filter must hook in. Till now i thaught this
must be PORTS, because this shown there, too.

Then I’m confused. Are you saying that the device monitors the data
stream to watch for certain “escape” sequences? Usually, that’s a very
bad idea, because it means those byte sequences cannot be sent in the
normal data stream. The modem world tried a number of things before
settling on the now infamous “+++” attention sequence for sending modem
commands, and even that sequence has timing constraints to make sure you
don’t accidentally go to modem mode when sending a line like /* +++++
Tastes great! +++++ */

Isn’t there a Bluetooth standard for COM ports? Does your device not
conform to that standard?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

Ok, so as I understand it now, you want to place an UpperFilter on the
(virtual) COM port device created by the Bluetooth stack (BTENUM) in
response to an SPP profile being enumerated on your device.

I believe that can be accomplished by standard SetupDi style operations
which amount to adding your driver service name to the UpperFilters
REG_MULTI_SZ of the DevNode.

Of course enumeration of SPP profiles into virtual ‘devices’ is stack
specific and thus what you do for one stack (MSFT or WIDCOMM) might not work
for another stack.

To manually find what DevNode your device is in the PnP database use DevMgr
to show the properties on the (virtual) Port device. The property “Device
Instance Path” is the subpath from HKLM\Control\Enum to the HW
configuration. As an example, the generic SPP COM port on my Nokia phone
enumerates as

BTHENUM{00001101-0000-1000-8000-00805F9B34FB}_VID&00010001_PID&1856\7&F819B
74&0&00025B00A5A5_C00000002

The driver on this particular device is BTHMODEM and there are no other
filters (upper or lower). BTHMODEM is acting as the FDO in this case.

Other situations (where it is actually a Modem) often have BTHMODEM as a
lower filter and MODEM (Unimodem) as the FDO, or, alternatively I have seen
where a driver *like* BTHMODEM is the FDO and MODEM (Unimodem) is an upper
filter.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hannes Finck
Sent: Thursday, November 06, 2008 11:37 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Serial Filter Driver

Hi David,

The bluetooth device already looks like a COM port to the system. It
offers a virtual COM port, software can communicate with. I want a
filter driver that can manipulate data coming from the usermode software
and going to the virtual COM port. I don’t know if this might help you,
but the device shows up under the COM port section in FilterMan. It is
enumerated by BTHENUM (Service: BTHMODEM). I don’t exactly know where
the filter must hook in. Till now i thaught this must be PORTS, because
this shown there, too.

Sorry for the incomplete description, this is my first attempt of
developing a driver.

Regards
Hannes

David R. Cattley schrieb:

Hannes,

Do you want the device to look like a serial port to the OS or do you want
the device to look like a Bluetooth radio? (or perhaps it is a serial
attached radio device that pairs with a SPP device you want to look like a
serial port to the OS?)

Is the device actually a serial port integrated into the system or does it
attach to a real/generic serial port and enumerate via SerEnum?

If you can do a more complete job of describing the actual hardware
attachment and enumerated driver stack it would be easier to suggest how
you
might accomplish your goal.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hannes Finck
Sent: Thursday, November 06, 2008 9:58 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Serial Filter Driver

Hi,

I want do develop a filter driver for a bluetooth device that registers
itself as a COM port. If a software opens a handle to the device and
sets parameters like baud rate the driver should block this and instead
send a specified string to the device. Now i have this filter sample
from the toaster directory and don’t really know how I should realize
this. Can anyone tell me (in theory) what i have to do to achieve this
functionality? I don’t know from which event i have to open a queue and
how to access the data in the incoming IRP. I think it must be
IPR_MJ_CREATE and IRP_MJ_DEVICE_CONTROL (Serial Device Controle
Request?), right?

Thank you in advance.
Hannes

NTDEV is sponsored by OSR

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

NTDEV is sponsored by OSR

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

6

Tim Roberts wrote:

The modem world tried a number of things before settling on
the now infamous “+++” attention sequence for sending modem
commands, and even that sequence has timing constraints to
make sure you don’t accidentally go to modem mode when sending
a line like /* +++++ Tastes great! +++++ */

I used to kick people off IRC by sending them a ping (i.e. ICMP_ECHO) with “+++ATH0\r” in the payload. Their machine would echo the packet back, parse the “+++ATH0\r” out of the packet, and promptly hang up. Ah, IRC…

7

Maybe i should explain what this device actually does. This device is
for reading out information out of an electricity meter. These meters
have an IR interface and the bluetooth device has one, too. It reads and
sends data to the meter via IR and sends the data to the pc via
bluetooth, where software can read it out from the COM port. If software
wants to change settings of communication (i.e baud rate), the bluetooth
device expects some controle bytes (i.e 0x80 F), because it doesn’t
recognize there is a software changing connection settings. The software
only changes settings between itself and the virtual com port, but the
settings between IR head (the bluetooth device)and e-meter must be
changed, too, to match with the software. So the IR head expects these
controle bytes for this. The software doesn’t know, that it need’s to
send this controle bytes to the COM port, so the filter driver needs to
generate WRITES with the specified controle bytes every time the
software changes settings (start bits, stop bits, parity…) uhh… i
hope you can understand now what the driver should do :wink: I try to
understand WDF and KMDF, but i need some design help, because I’m
absolutely unexperienced in writing drivers. I’m from the “usermode”
side :wink:

Regards
Hannes

8

Hannes,

So you want to:

  1. Intercept the IRP_MJ_DEVICE_CONTROL for setting the format on the
    virtual serial port *before* the virtual serial port driver (BTHMODEM is the
    likely driver in this case) processes the request. You do this with an
    UpperFilter.

  2. Pend the IRP_MJ_DEVICE_CONTROL request in your UpperFilter.

  3. Create a request (an IRP_MJ_WRITE) with the escape sequence and send
    that down the stack so that the IR Dongle and meter can process it. (I
    assume it does not generate any response).

  4. Send the original IRP_MJ_DEVICE_CONTROL request down the stack so that
    BTHMODEM can process it (and send it along to the serial profile on the
    wiz-bang bth/ir hand-held reader device).

Is that it?

If the only way to solve this is without changing the software running in
usermode (for what it is worth, I would try to do it there if I could - make
the custom reader app aware that it is using the bth/ir reader and just deal
with it) then you need an UpperFilter stuffed between the Win32 COM client
and the port FDO.

I hope your application is not using the MSCOMM.OCX control. That piece of
crap will make your task even harder since it may not be very happy about
trying to pend and IRP sent to change the format.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hannes Finck
Sent: Thursday, November 06, 2008 5:09 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Serial Filter Driver

Maybe i should explain what this device actually does. This device is
for reading out information out of an electricity meter. These meters
have an IR interface and the bluetooth device has one, too. It reads and
sends data to the meter via IR and sends the data to the pc via
bluetooth, where software can read it out from the COM port. If software
wants to change settings of communication (i.e baud rate), the bluetooth
device expects some controle bytes (i.e 0x80 F), because it doesn’t
recognize there is a software changing connection settings. The software
only changes settings between itself and the virtual com port, but the
settings between IR head (the bluetooth device)and e-meter must be
changed, too, to match with the software. So the IR head expects these
controle bytes for this. The software doesn’t know, that it need’s to
send this controle bytes to the COM port, so the filter driver needs to
generate WRITES with the specified controle bytes every time the
software changes settings (start bits, stop bits, parity…) uhh… i
hope you can understand now what the driver should do :wink: I try to
understand WDF and KMDF, but i need some design help, because I’m
absolutely unexperienced in writing drivers. I’m from the “usermode”
side :wink:

Regards
Hannes

NTDEV is sponsored by OSR

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

9

Hi David,

You hit the nail on the head. Unfortunately, the usermode software is
not from our company so they need this driver to be able to communicate
with our dongle. I thank you very much for giving me this guideline.
This makes my life much easier. Do you know which event I have to
register to have a dispatch routine for IRP_MJ_DEVICE_CONTROLE? Till now
I’m spending most of my time to understand KMDF and how this whole thing
works. Actually, I’m glad to know what you are talking about and this
shows me I’m slowly getting into it. Thank you.
Oh, one thing. For which class and GUID do I have to register the filter
for? I used PORTS, but I’m not sure if this is right.

Thank you so far (this is probably not my last question ^^)
Hannes

David R. Cattley schrieb:

Hannes,

So you want to:

  1. Intercept the IRP_MJ_DEVICE_CONTROL for setting the format on the
    virtual serial port *before* the virtual serial port driver (BTHMODEM is the
    likely driver in this case) processes the request. You do this with an
    UpperFilter.

  2. Pend the IRP_MJ_DEVICE_CONTROL request in your UpperFilter.

  3. Create a request (an IRP_MJ_WRITE) with the escape sequence and send
    that down the stack so that the IR Dongle and meter can process it. (I
    assume it does not generate any response).

  4. Send the original IRP_MJ_DEVICE_CONTROL request down the stack so that
    BTHMODEM can process it (and send it along to the serial profile on the
    wiz-bang bth/ir hand-held reader device).

Is that it?

If the only way to solve this is without changing the software running in
usermode (for what it is worth, I would try to do it there if I could - make
the custom reader app aware that it is using the bth/ir reader and just deal
with it) then you need an UpperFilter stuffed between the Win32 COM client
and the port FDO.

I hope your application is not using the MSCOMM.OCX control. That piece of
crap will make your task even harder since it may not be very happy about
trying to pend and IRP sent to change the format.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

10

Why not develop the user mode software so it will send only the task-specific proper commands to the port?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

“Hannes Finck” wrote in message news:xxxxx@ntdev…
> Maybe i should explain what this device actually does. This device is
> for reading out information out of an electricity meter. These meters
> have an IR interface and the bluetooth device has one, too. It reads and
> sends data to the meter via IR and sends the data to the pc via
> bluetooth, where software can read it out from the COM port. If software
> wants to change settings of communication (i.e baud rate), the bluetooth
> device expects some controle bytes (i.e 0x80 F), because it doesn’t
> recognize there is a software changing connection settings. The software
> only changes settings between itself and the virtual com port, but the
> settings between IR head (the bluetooth device)and e-meter must be
> changed, too, to match with the software. So the IR head expects these
> controle bytes for this. The software doesn’t know, that it need’s to
> send this controle bytes to the COM port, so the filter driver needs to
> generate WRITES with the specified controle bytes every time the
> software changes settings (start bits, stop bits, parity…) uhh… i
> hope you can understand now what the driver should do :wink: I try to
> understand WDF and KMDF, but i need some design help, because I’m
> absolutely unexperienced in writing drivers. I’m from the “usermode”
> side :wink:
>
> Regards
> Hannes
>

11

Maxim S. Shatksih wrote:

Why not develop the user mode software so it will send only the
task-specific proper commands to the port?

Why do you reply with this suggestion over an hour after the guy already said he can’t change the usermode software?

12

Maybe there’s a simpler way:

  • Set the comm parameters once and forever on both sides.
  • Then, silently drop any app ioctl that attempts to change these
    settings.

–PA

David R. Cattley wrote:

Hannes,

So you want to:

  1. Intercept the IRP_MJ_DEVICE_CONTROL for setting the format on the
    virtual serial port *before* the virtual serial port driver (BTHMODEM is the
    likely driver in this case) processes the request. You do this with an
    UpperFilter.

  2. Pend the IRP_MJ_DEVICE_CONTROL request in your UpperFilter.

  3. Create a request (an IRP_MJ_WRITE) with the escape sequence and send
    that down the stack so that the IR Dongle and meter can process it. (I
    assume it does not generate any response).

  4. Send the original IRP_MJ_DEVICE_CONTROL request down the stack so that
    BTHMODEM can process it (and send it along to the serial profile on the
    wiz-bang bth/ir hand-held reader device).

Is that it?

If the only way to solve this is without changing the software running in
usermode (for what it is worth, I would try to do it there if I could - make
the custom reader app aware that it is using the bth/ir reader and just deal
with it) then you need an UpperFilter stuffed between the Win32 COM client
and the port FDO.

I hope your application is not using the MSCOMM.OCX control. That piece of
crap will make your task even harder since it may not be very happy about
trying to pend and IRP sent to change the format.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hannes Finck
Sent: Thursday, November 06, 2008 5:09 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Serial Filter Driver

Maybe i should explain what this device actually does. This device is
for reading out information out of an electricity meter. These meters
have an IR interface and the bluetooth device has one, too. It reads and
sends data to the meter via IR and sends the data to the pc via
bluetooth, where software can read it out from the COM port. If software
wants to change settings of communication (i.e baud rate), the bluetooth
device expects some controle bytes (i.e 0x80 F), because it doesn’t
recognize there is a software changing connection settings. The software
only changes settings between itself and the virtual com port, but the
settings between IR head (the bluetooth device)and e-meter must be
changed, too, to match with the software. So the IR head expects these
controle bytes for this. The software doesn’t know, that it need’s to
send this controle bytes to the COM port, so the filter driver needs to
generate WRITES with the specified controle bytes every time the
software changes settings (start bits, stop bits, parity…) uhh… i
hope you can understand now what the driver should do :wink: I try to
understand WDF and KMDF, but i need some design help, because I’m
absolutely unexperienced in writing drivers. I’m from the “usermode”
side :wink:

Regards
Hannes

NTDEV is sponsored by OSR

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

13

Hi,

Sorry, this is not possible, because software must be able to change
connection seetings. If i set fixed values and the software wants to
change something, the settings don’t match on both sides and
communication is no longer possible :frowning:

Pavel A. schrieb:

Maybe there’s a simpler way:

  • Set the comm parameters once and forever on both sides.
  • Then, silently drop any app ioctl that attempts to change these
    settings.

–PA

David R. Cattley wrote:
> Hannes,
>
> So you want to:
>
> 1. Intercept the IRP_MJ_DEVICE_CONTROL for setting the format on the
> virtual serial port *before* the virtual serial port driver (BTHMODEM
> is the
> likely driver in this case) processes the request. You do this with an
> UpperFilter.
>
> 2. Pend the IRP_MJ_DEVICE_CONTROL request in your UpperFilter.
>
> 3. Create a request (an IRP_MJ_WRITE) with the escape sequence and send
> that down the stack so that the IR Dongle and meter can process it. (I
> assume it does not generate any response).
>
> 4. Send the original IRP_MJ_DEVICE_CONTROL request down the stack so
> that
> BTHMODEM can process it (and send it along to the serial profile on the
> wiz-bang bth/ir hand-held reader device).
>
> Is that it?
>
> If the only way to solve this is without changing the software running in
> usermode (for what it is worth, I would try to do it there if I could
> - make
> the custom reader app aware that it is using the bth/ir reader and
> just deal
> with it) then you need an UpperFilter stuffed between the Win32 COM
> client
> and the port FDO.
>
> I hope your application is not using the MSCOMM.OCX control. That
> piece of
> crap will make your task even harder since it may not be very happy about
> trying to pend and IRP sent to change the format.
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Hannes Finck
> Sent: Thursday, November 06, 2008 5:09 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Serial Filter Driver
>
> Maybe i should explain what this device actually does. This device is
> for reading out information out of an electricity meter. These meters
> have an IR interface and the bluetooth device has one, too. It reads
> and sends data to the meter via IR and sends the data to the pc via
> bluetooth, where software can read it out from the COM port. If software
> wants to change settings of communication (i.e baud rate), the
> bluetooth device expects some controle bytes (i.e 0x80 F), because it
> doesn’t recognize there is a software changing connection settings.
> The software only changes settings between itself and the virtual com
> port, but the settings between IR head (the bluetooth device)and
> e-meter must be changed, too, to match with the software. So the IR
> head expects these controle bytes for this. The software doesn’t know,
> that it need’s to send this controle bytes to the COM port, so the
> filter driver needs to
> generate WRITES with the specified controle bytes every time the
> software changes settings (start bits, stop bits, parity…) uhh…
> i hope you can understand now what the driver should do :wink: I try to
> understand WDF and KMDF, but i need some design help, because I’m
> absolutely unexperienced in writing drivers. I’m from the “usermode”
> side :wink:
>
> Regards
> Hannes
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
>

14

Hi,

Does anyone know what I need to change in the inf from the
/toaster/filter sample? I inserted class PORTS and the associated GUID.
I thought this is right, because the device is shown as a COM port.