Prev: Problem attaching WinDbg to target after WDK7600 upgrade
Next: RDF_CARD_TRACKING
From: embedinfo on 13 Nov 2009 05:03
Hi all,

I am new to PC driver development. I would like to write USB packet
monitoring tool. Based on my reading I have decided to write USB upper
filter class driver.

I started with
<Install Root>\WinDDK\7600.16385.0\src\general\toaster\kmdf\filter
\sideband

As a first step I added few DbgPrint messages all over the filter
function and registered filter as Upper filter class to USB stack.

I added following to FilterEvtIoDeviceControl() to track IOCTL's being
called from client drivers:

switch(IoControlCode)
{

case IOCTL_INTERNAL_USB_SUBMIT_URB:
DbgPrint("IOCTL_INTERNAL_USB_SUBMIT_URB\n");
break;

case IOCTL_INTERNAL_USB_RESET_PORT:
DbgPrint("IOCTL_INTERNAL_USB_RESET_PORT\n");
break;

case IOCTL_INTERNAL_USB_GET_PORT_STATUS:
DbgPrint("IOCTL_INTERNAL_USB_GET_PORT_STATUS\n");
break;

case IOCTL_INTERNAL_USB_ENABLE_PORT:
DbgPrint("IOCTL_INTERNAL_USB_ENABLE_PORT\n");
break;

case IOCTL_INTERNAL_USB_GET_HUB_COUNT:
DbgPrint("IOCTL_INTERNAL_USB_GET_HUB_COUNT\n");
break;

case IOCTL_INTERNAL_USB_CYCLE_PORT:
DbgPrint("IOCTL_INTERNAL_USB_CYCLE_PORT\n");
break;

case IOCTL_INTERNAL_USB_GET_ROOTHUB_PDO:
DbgPrint("IOCTL_INTERNAL_USB_GET_ROOTHUB_PDO\n");
break;

case IOCTL_INTERNAL_USB_GET_HUB_NAME:
DbgPrint("IOCTL_INTERNAL_USB_GET_HUB_NAME\n");
break;

case IOCTL_INTERNAL_USB_GET_BUS_INFO:
DbgPrint("IOCTL_INTERNAL_USB_GET_BUS_INFO\n");
break;

case IOCTL_INTERNAL_USB_GET_CONTROLLER_NAME:
DbgPrint("IOCTL_INTERNAL_USB_GET_CONTROLLER_NAME\n");
break;

case IOCTL_INTERNAL_USB_SUBMIT_IDLE_NOTIFICATION:
DbgPrint("IOCTL_INTERNAL_USB_SUBMIT_IDLE_NOTIFICATION\n");
break;

default:
DbgPrint("Invalid IOCTL 0x%x\n", IoControlCode);
//status = STATUS_INVALID_DEVICE_REQUEST;
break;
}

But after rebooting machine I just see following IOCTL being called:

"IOCTL_INTERNAL_USB_GET_CONTROLLER_NAME" and some invalid IOCTL with
hex code ("0x220408")

I was expecting "IOCTL_INTERNAL_USB_SUBMIT_URB" call which is not
called at all.

Can any one tell me if this is the right way to write USB packet
monitoring tool? If yes I surprised why IOCTL_INTERNAL_USB_SUBMIT_URB
is not being called.

Any help would be appreciated!

Thanks
From: Tim Roberts on 13 Nov 2009 23:50
embedinfo <embedinfo(a)gmail.com> wrote:
>
>I am new to PC driver development. I would like to write USB packet
>monitoring tool. Based on my reading I have decided to write USB upper
>filter class driver.

Upper filter to which class?

>As a first step I added few DbgPrint messages all over the filter
>function and registered filter as Upper filter class to USB stack.

Do you mean USB class, {36FC9E60-...}? Remember, that class includes host
controllers, hubs, composite devices, and many other devices. Anything
that appears in Device Manager under "Universal Serial Bus controllers".
You're going to be intercepting ALL communications heading into ANY of
those devices.

>But after rebooting machine I just see following IOCTL being called:
>
>"IOCTL_INTERNAL_USB_GET_CONTROLLER_NAME" and some invalid IOCTL with
>hex code ("0x220408")

It's not invalid:
00220408 = IOCTL_USB_GET_NODE_INFORMATION
00220408 = IOCTL_USB_GET_ROOT_HUB_NAME

>I was expecting "IOCTL_INTERNAL_USB_SUBMIT_URB" call which is not
>called at all.

It sounds like you may have intercepted IRP_MJ_DEVICE_CONTROL instead of
IRP_MJ_INTERNAL_DEVICE_CONTROL. Is that possible?

>Can any one tell me if this is the right way to write USB packet
>monitoring tool?

It's one way to do it. Are you aware there are already quite a number of
tools that do this, including some that are free?
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: embedinfo on 14 Nov 2009 07:01
Hi Robert,

Thanks for quick response. Please find answers to the questions with
some more queries inline:

On Nov 14, 9:50 am, Tim Roberts <t...(a)probo.com> wrote:
> embedinfo <embedi...(a)gmail.com> wrote:
>
> >I am new to PC driver development. I would like to write USB packet
> >monitoring tool. Based on my reading I have decided to write USB upper
> >filter class driver.
>
> Upper filter to which class? {36FC9E60...

I am writing upper filter to USB class.
>
> >As a first step I added few DbgPrint messages all over the filter
> >function and registered filter as Upper filter class to USB stack.
>
> Do you mean USB class, {36FC9E60-...}?  Remember, that class includes host
> controllers, hubs, composite devices, and many other devices.  Anything
> that appears in Device Manager under "Universal Serial Bus controllers".
> You're going to be intercepting ALL communications heading into ANY of
> those devices.

Is this the right appraoch? Please suggest any better way!
>
> >But after rebooting machine I just see following IOCTL being called:
>
> >"IOCTL_INTERNAL_USB_GET_CONTROLLER_NAME" and some invalid IOCTL with
> >hex code ("0x220408")
>
> It's not invalid:
>   00220408 = IOCTL_USB_GET_NODE_INFORMATION
>   00220408 = IOCTL_USB_GET_ROOT_HUB_NAME

Actually I checked these IOCTL hex code in OSR online, and I could not
find any explanation about these. Where can I find explanation about
these IOCTLs?
>
> >I was expecting "IOCTL_INTERNAL_USB_SUBMIT_URB" call which is not
> >called at all.
>
> It sounds like you may have intercepted IRP_MJ_DEVICE_CONTROL instead of
> IRP_MJ_INTERNAL_DEVICE_CONTROL.  Is that possible?
>
Even I am not sure about this. I am planning to connect WinDbg and
track the caller.

> >Can any one tell me if this is the right way to write USB packet
> >monitoring tool?
>
> It's one way to do it.  Are you aware there are already quite a number of
> tools that do this, including some that are free?

Yes. I used couple of them and this activity I have chosen this
activity myself to get a feel of Windows Driver programming. Any help
would be greatly appreciated.
> --
> Tim Roberts, t...(a)probo.com
> Providenza & Boekelheide, Inc.

From: Tim Roberts on 15 Nov 2009 17:27
embedinfo <embedinfo(a)gmail.com> wrote:
>>
>> It's not invalid:
>> � 00220408 = IOCTL_USB_GET_NODE_INFORMATION
>> � 00220408 = IOCTL_USB_GET_ROOT_HUB_NAME
>
>Actually I checked these IOCTL hex code in OSR online, and I could not
>find any explanation about these. Where can I find explanation about
>these IOCTLs?

Google will point you to the MSDN pages. Mostly, these are for internal
communication between the hubs and host controller and should not be of
interest.


>> It sounds like you may have intercepted IRP_MJ_DEVICE_CONTROL instead of
>> IRP_MJ_INTERNAL_DEVICE_CONTROL. �Is that possible?
>>
>Even I am not sure about this. I am planning to connect WinDbg and
>track the caller.

??? YOU wrote the filter driver, right? Only YOU know which requests you
asked to intercept. You need WdfRequestTypeDeviceControlInternal, not
WdfRequestTypeDeviceControl.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: embedinfo on 16 Nov 2009 12:08
Sorry for all confusion I created. Let me re-frame my question as
follows:

<WDK>\src\general\toaster\kmdf\filter\sideband has registered only
one callback function as follows to handle Major IOCTLs:

ioQueueConfig.EvtIoDeviceControl = FilterEvtIoDeviceControl;

But this template doesn't handle internal IOCTLs such as
IOCTL_INTERNAL_SUBMIT_URB. I would like to catch URB packet at this
level.

So I registered my own internal handler function, where in I have
handled internal IOCTLs:

ioQueueConfig.EvtInternalIoDeviceControl =
FilterEvtInternalIoDeviceControl;

I can see only "EvtIoDeviceControl " being called, but
"EvtInternalIoDeviceControl " is never called. Does any one know the
reason for this? Am I missing anything?

Thanks
 |  Next  |  Last
Pages: 1 2
Prev: Problem attaching WinDbg to target after WDK7600 upgrade
Next: RDF_CARD_TRACKING