Prev: Problem attaching WinDbg to target after WDK7600 upgrade
Next: RDF_CARD_TRACKING
From: Doron Holan [MSFT] on 16 Nov 2009 16:24
> 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.

choose something else. this is going to be a very complicated project and
not work the way you think it does. the usb stack has a few short cuts in
terms of URB processing and filters do not see the URB traffic for the most
part.

d

--

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


"embedinfo" <embedinfo(a)gmail.com> wrote in message
news:1f961133-fcca-42d2-8f7b-fff530c9d6eb(a)f20g2000prn.googlegroups.com...
> 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: embedinfo on 17 Nov 2009 22:45
On Nov 17, 2:24 am, "Doron Holan [MSFT]"
<doron.ho...(a)online.microsoft.com> wrote:
> > 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.
>
> choose something else.

Can you suggest better way to do this? Does it mean that this task
will be complecated using WDF frame work? or even with WDM model? or
is it complecated for begginer like me?

Then what technique is used in commercially available USB sniffers do
use? Any inputs will be helpful.

Thanks


 this is going to be a very complicated project and
> not work the way you think it does.  the usb stack has a few short cuts in
> terms of URB processing and filters do not see the URB traffic for the most
> part.
>
> d
>
>
From: Doron Holan [MSFT] on 20 Nov 2009 18:35
the latter. it is complicated no matter what framework you use.
commercially available usb sniffers play some dirty tricks and use
undocumented features. they are not products that were released overnight
either, they took years to develop and run properly. as a learning exercise
I would pick something simpler

d

--

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


"embedinfo" <embedinfo(a)gmail.com> wrote in message
news:57a0eb11-5e74-4dc9-8812-2373e6115776(a)z35g2000prh.googlegroups.com...
> On Nov 17, 2:24 am, "Doron Holan [MSFT]"
> <doron.ho...(a)online.microsoft.com> wrote:
>> > 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.
>>
>> choose something else.
>
> Can you suggest better way to do this? Does it mean that this task
> will be complecated using WDF frame work? or even with WDM model? or
> is it complecated for begginer like me?
>
> Then what technique is used in commercially available USB sniffers do
> use? Any inputs will be helpful.
>
> Thanks
>
>
> this is going to be a very complicated project and
>> not work the way you think it does. the usb stack has a few short cuts
>> in
>> terms of URB processing and filters do not see the URB traffic for the
>> most
>> part.
>>
>> d
>>
>>
First  |  Prev  | 
Pages: 1 2
Prev: Problem attaching WinDbg to target after WDK7600 upgrade
Next: RDF_CARD_TRACKING