Generic USB filter driver, is it possible?

NTDEV
1

(changing the subject).

I am not able to answer your question but I have forwarded this to
Travis, the current developer.

On the other hand, what is your suggestion for a generic filter driver?
Is it even possible to achieve the goal? Thanks a lot for the help
in advance.

On one hand, we prefer the users to use the device driver mode.
As per the wiki, we do not promote the filter driver to be
deployed to the end users, but rather it is more for
developer use.
http://sourceforge.net/apps/trac/libusb-win32/wiki

At one time, we even intended to deprecate the filter driver mode.
However, sometimes the device already have a function driver
and the user wants to stick to the original function driver for
its existing function yet he also wants to use libusb-win32
for certain function not available from the original function driver.
Therefore we can not give up the filter driver completely right
now. So we came out with the idea of limit the filter driver
to certain device only for the next release. Based on our
testing, it seems to work with the USB device we intended
to support (eg: FTDI device, device using other generic USB
driver like Microchip USB driver or WinUSB, etc).

Regards,
Xiaofan

On Tue, Sep 28, 2010 at 7:39 AM, Doron Holan wrote:
> Sending URBs directly to the PDO (or through the FDO in the
> event that the FDO mistakenly passes them through) is a really
> really bad design. You are communicating with the device or modifying
> the state of the device without coordination of the FDO (not to mention
> how I don’t know how you are even getting USBPIPE handles as an
> upper filter since you don’t see the config request the fdo sends), thus
> putting the FDO driver in an untested (and untestable/unsupported) state
>
> d

2

There is no such thing as a generic filter driver IMHO. The filter has to know the rules of the stack it is filtering. Using win32 nd libusb to access the same device instance is a recipe for disaster. You are getting *lucky* that it even works in your limited scenarios. Definitely not by design.

d

dent from a phpne with no keynoard

-----Original Message-----
From: Xiaofan Chen
Sent: September 27, 2010 7:05 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Generic USB filter driver, is it possible?

(changing the subject).

I am not able to answer your question but I have forwarded this to
Travis, the current developer.

On the other hand, what is your suggestion for a generic filter driver?
Is it even possible to achieve the goal? Thanks a lot for the help
in advance.

On one hand, we prefer the users to use the device driver mode.
As per the wiki, we do not promote the filter driver to be
deployed to the end users, but rather it is more for
developer use.
http://sourceforge.net/apps/trac/libusb-win32/wiki

At one time, we even intended to deprecate the filter driver mode.
However, sometimes the device already have a function driver
and the user wants to stick to the original function driver for
its existing function yet he also wants to use libusb-win32
for certain function not available from the original function driver.
Therefore we can not give up the filter driver completely right
now. So we came out with the idea of limit the filter driver
to certain device only for the next release. Based on our
testing, it seems to work with the USB device we intended
to support (eg: FTDI device, device using other generic USB
driver like Microchip USB driver or WinUSB, etc).

Regards,
Xiaofan

On Tue, Sep 28, 2010 at 7:39 AM, Doron Holan wrote:
> Sending URBs directly to the PDO (or through the FDO in the
> event that the FDO mistakenly passes them through) is a really
> really bad design. You are communicating with the device or modifying
> the state of the device without coordination of the FDO (not to mention
> how I don’t know how you are even getting USBPIPE handles as an
> upper filter since you don’t see the config request the fdo sends), thus
> putting the FDO driver in an untested (and untestable/unsupported) state
>
> d

—
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

Thanks for the answer. I am not a software engineer myself
(I am a hardware engineer who happens to be interested in
USB quite a bit). I will tend to trust experts like you
(and Tim) in terms of USB driver under Windows.

I will relay your message to Travis.

On the other hand, libusb-win32 has been around for years
(since 2004). The filter driver seemed to work fine under
Windows 98SE/ME and Win2k, there were issues with
Windows XP, then lots of issues with Vista and Windows 7.
Once upon a time, even a Microsoft guy filed a negative review
on the website. I myself shifted the focus to support libusb-1.0
Windows backend which starts with WinUSB support and
later added HID support.

When Travis Robinson and I took over the libusb-win32 project
this year, we were thinking that the bug raised by Tim Roberts
is the main issue with the filter (Filter driver should not be
power policy owner).
http://sourceforge.net/tracker/?func=detail&aid=2658937&group_id=78138&atid=552262

Once we fixed this one, so far we have not heard major problems
any more. Yes there are still issues with some device using
WinUSB/UMDF or wudfrd.sys because of power management issues.
What we are trying now is to limit the filter driver to certain device
and warn the users about the potential problems.

So in practice, it does work for many USB device in the field.
We have not given up on the filter driver as yet right now. But
we certainly would like to listen to the experts and see our
future options.

Regards,
Xiaofan

On Tue, Sep 28, 2010 at 2:39 PM, Doron Holan wrote:
> There is no such thing as a generic filter driver IMHO. The filter has
> to know the rules of the stack it is filtering. Using win32 nd libusb to
> access the same device instance is a recipe for disaster. You are
> getting lucky that it even works in your limited scenarios. Definitely
> not by design.
>
> ?d
>
> dent from a phpne with no keynoard
>
> -----Original Message-----
> From: Xiaofan Chen
> Sent: September 27, 2010 7:05 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Generic USB filter driver, is it possible?
>
>
> (changing the subject).
>
> I am not able to answer your question but I have forwarded this to
> Travis, the current developer.
>
> On the other hand, what is your suggestion for a generic filter driver?
> Is it even possible to achieve the goal? Thanks a lot for the help
> in advance.
>
> On one hand, we prefer the users to use the device driver mode.
> As per the wiki, we do not promote the filter driver to be
> deployed to the end users, but rather it is more for
> developer use.
> http://sourceforge.net/apps/trac/libusb-win32/wiki
>
> At one time, we even intended to deprecate the filter driver mode.
> However, sometimes the device already have a function driver
> and the user wants to stick to the original function driver for
> its existing function yet he also wants to use libusb-win32
> for certain function not available from the original function driver.
> Therefore we can not give up the filter driver completely right
> now. So we came out with the idea of limit the filter driver
> to certain device only for the next release. Based on our
> testing, it seems to work with the USB device we intended
> to support (eg: FTDI device, device using other generic USB
> driver like Microchip USB driver or WinUSB, etc).
>
>
> Regards,
> Xiaofan
>
>
>
> On Tue, Sep 28, 2010 at 7:39 AM, Doron Holan wrote:
>> Sending URBs directly to the PDO (or through the FDO in the
>> event that the FDO mistakenly passes them through) is a really
>> really bad design. You are communicating with the device or modifying
>> the state of the device without coordination of the FDO (not to mention
>> how I don’t know how you are even getting USBPIPE handles as an
>> upper filter since you don’t see the config request the fdo sends), thus
>> putting the FDO driver in an untested (and untestable/unsupported) state
>>
>> d
>

4

> On the other hand, what is your suggestion for a generic filter driver? Is it even possible to achieve

the goal?

Theoretically yes - indeed, you can write a “generic” filter that passes everything down the stack. However, this is the absolute maximum that you can expect from a “generic” filter- if you want to give it more or less meaningful functionality you have to be specific about your targets, know exactly what you are about to filter and do it in accordance with the API contract for a particular device stack …

Anton Bassov

5

On Tue, Sep 28, 2010 at 4:30 PM, wrote:
>
>> On the other hand, what is your suggestion for a
>> generic filter driver? Is it even possible to achieve
>>the goal?
>
> Theoretically yes - indeed, you can write a “generic” filter that
> passes everything down the stack. However, this is the absolute
> maximum that you can expect from a “generic” filter- if you want
> to give it more or less meaningful functionality you have to be specific
> about your targets, know exactly what you are about to filter and do
> it in accordance with the API contract for a particular device stack …
>
> Anton Bassov

The original goal is to support libusb-0.1 API and some extensions.
http://libusb.sourceforge.net/doc/
http://sourceforge.net/apps/trac/libusb-win32/wiki/libusbwin32_documentation

We also intend to support the new (better) libusb-1.0 API.
http://libusb.sourceforge.net/api-1.0/

Under Linux, you do not need a kernel driver to use libusb. Under
Windows, you need one. So libusb-win32 kernel driver
was developed. The device driver mode works fine for this
purpose and is the recommended way from us. The filter driver
mode seems to work as well so far for many USB device.
Again we do see potential problems with the filter driver but
we are trying to fix it as far as possible.

Again the driver and other things (user space library, driver
installer, test programs) are here.
http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/branches/libusb-testing/

I understand most of the people here will be too busy to
read the codes. :wink: So I just list two relatively important files
here for you to take a glance. Again comments are welcome.
http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/branches/libusb-testing/src/driver/dispatch.c?revision=364&view=markup
http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/branches/libusb-testing/src/driver/ioctl.c?revision=313&view=markup

BTW, we also make use of libwdi (LGPL) here. It might be useful
to some people here.
http://www.libusb.org/wiki/libwdi

–
Xiaofan

6

On Tue, Sep 28, 2010 at 2:39 PM, Doron Holan wrote:
> There is no such thing as a generic filter driver IMHO. The filter has to know the
> rules of the stack it is filtering.

What about those USB sniffer software’s kernel driver? It seems to
me they are generic filter (lower filter) driver.

–
Xiaofan

7

There certainly are ‘generic usb filter drivers’, aka ‘usb bus filter
drivers’ that filter at the usb pdo level and are agnostic to the type of
usb device being filtered. They do understand the usb stack of course. Usb
sniffers are an example.

Mark Roddy

On Tue, Sep 28, 2010 at 8:48 AM, Xiaofan Chen wrote:

> On Tue, Sep 28, 2010 at 2:39 PM, Doron Holan
> wrote:
> > There is no such thing as a generic filter driver IMHO. The filter has to
> know the
> > rules of the stack it is filtering.
>
> What about those USB sniffer software’s kernel driver? It seems to
> me they are generic filter (lower filter) driver.
>
> –
> Xiaofan
>
> —
> 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
>

8

Xiaofan Chen wrote:

On Tue, Sep 28, 2010 at 2:39 PM, Doron Holan wrote:
>> There is no such thing as a generic filter driver IMHO. The filter has to know the
>> rules of the stack it is filtering.
> What about those USB sniffer software’s kernel driver? It seems to
> me they are generic filter (lower filter) driver.

I would certainly not call those generic filters. They are very
specific filters. They speak URBs. They are specific to the Windows
USB protocol.

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

9

On Wed, Sep 29, 2010 at 1:42 AM, Tim Roberts wrote:
> ?Xiaofan Chen wrote:
>> On Tue, Sep 28, 2010 at 2:39 PM, Doron Holan wrote:
>>> There is no such thing as a generic filter driver IMHO. The filter has to know the
>>> rules of the stack it is filtering.
>> What about those USB sniffer software’s kernel driver? It seems to
>> me they are generic filter (lower filter) driver.
>
> I would certainly not call those generic filters. ?They are very
> specific filters. ?They speak URBs. ?They are specific to the Windows
> USB protocol.
>

I can agree with you. Thanks. In one way it is generic since it
applies to many USB device. But you are right, they are only
for very special purpose.

The libusb-win32 filter is much more broader and therefore
much more problematic. If we deprecate it, life would be
much easier for us and then what is the fun. :wink: On the
other hand, if it comes to a point that it is too problematic
for us to maintain, then we have to remove it. So far we have
not come to that point yet.

Tim: what is your opinion about the libusb-win32 filter?
Does it have a future?

If it can not be done by external entity, maybe a system level
thing (windows kernel side) can be done. For example, FreeBSD
8/9 ugen driver is kind of interesting. It is attached to many device
along with the real driver. So you can use libusb or other generic API
with it without changing the driver. Under Linux, you have the way
to detach a kernel driver, so there is no issue for Linux. But for
Windows and Mac OS X, there is no such facility to detach the
kernel driver using a easy programmable way. So a generic filter
seems to be a good way if it can be achieved.

–
Xiaofan

10

> There certainly are ‘generic usb filter drivers’, aka ‘usb bus filter drivers’ that filter at the usb pdo level

and are agnostic to the type of usb device being filtered.

I would rather stick strictly with the latter definition - these are lower filters that sit in between FDOs and PDOs
and are device-type-agnostic by the definition of being lower drivers. However, IMHO, there is still nothing particularly “generic” about them…

Anton Bassov

11

The OP’s question was “Generic USB filter driver, is it possible?” not
“Generic filter driver, is it possible?”. A bus filter driver is generic -
device type agnostic - for its bus.

Mark Roddy

On Tue, Sep 28, 2010 at 11:15 PM, wrote:

>
> > There certainly are ‘generic usb filter drivers’, aka ‘usb bus filter
> drivers’ that filter at the usb pdo level
> > and are agnostic to the type of usb device being filtered.
>
> I would rather stick strictly with the latter definition - these are lower
> filters that sit in between FDOs and PDOs
> and are device-type-agnostic by the definition of being lower drivers.
> However, IMHO, there is still nothing particularly “generic” about
> them…
>
>
> Anton Bassov
>
> —
> 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
>

12

>The OP’s question was “Generic USB filter driver, is it possible?” not “Generic filter driver, is it possible?”.

A bus filter driver is generic - device type agnostic - for its bus.

OK, let’s leave it like that…

As they say, when people are just desperate to argue but have nothing to say on the actual topic…well, then they start arguing about the terminology used in a discussion. We don’t really want to take that venue, do we…

Anton Bassov

13

On Wed, Sep 29, 2010 at 11:06 AM, Xiaofan Chen wrote:
> The libusb-win32 filter is much more broader and therefore
> much more problematic. If we deprecate it, life would be
> much easier for us and then what is the fun. :wink: On the
> other hand, if it comes to a point that it is too problematic
> for us to maintain, then we have to remove it. So far we have
> not come to that point yet.
>
> Tim: what is your opinion about the libusb-win32 filter?
> Does it have a future?

Any comments here? Thanks.

> If it can not be done by external entity, maybe a system level
> thing (windows kernel side) can be done. For example, FreeBSD
> 8/9 ugen driver is kind of interesting. It is attached to many device
> along with the real driver. So you can use libusb or other generic API
> with it without changing the driver. Under Linux, you have the way
> to detach a kernel driver, so there is no issue for Linux. But for
> Windows and Mac OS X, there is no such facility to detach the
> kernel driver using a easy programmable way. So a generic filter
> seems to be a good way if it can be achieved.
>

Any comments? Thanks.

–
Xiaofan