[Libusb-devel] How to generate an ABORT_PIPE and RESET_PIPE URB

[l***@jumpstation.co.uk]

hi,

I am sure this has been asked before but for the last week I have been trying
to get to
http://sourceforge.net/mailarchive/forum.php?forum_name=libusb-devel
and I always get a 505, anyone got a tar ball of the last few years discussion
or a mirror to the archive ?

I have been using libusb in Linux very successfully in recreating URBs
matching those I had captured in USBSnoopyPro but two URBs elude me.

ABORT_PIPE and RESET_PIPE, neither are assigned an endpoint and both are used
in batches 4. Four RESET_PIPEs following four ABORT_PIPEs.

In USBSnoopyPro the only data for the URB is
URB Header (length: 24)
SequenceNumber: ##
Function: 0002 (ABORT_PIPE)
and
URB Header (length: 24)
SequenceNumber: ##
Function: 001e (RESET_PIPE)
where ## is the various sequence numbers.

Any ideas ?

Regards

Rob

[Tim Roberts]

Post by l***@jumpstation.co.uk
ABORT_PIPE and RESET_PIPE, neither are assigned an endpoint and both are used
in batches 4. Four RESET_PIPEs following four ABORT_PIPEs.
In USBSnoopyPro the only data for the URB is
URB Header (length: 24)
SequenceNumber: ##
Function: 0002 (ABORT_PIPE)
and
URB Header (length: 24)
SequenceNumber: ##
Function: 001e (RESET_PIPE)
where ## is the various sequence numbers.
Any ideas ?

These are both software requests to the host controller driver. They
don't actually cause any USB traffic. ABORT_PIPE asks the host
controller driver to abort any outstanding URBs that have not already
been sent to the hardware. There is a usbfs ioctl that maps to this for
asynchronous requests, but I don't know about synchronous.

RESET_PIPE asks the host controller to reset its understanding of the
endpoint's state back to the initial conditions. The usb_resetep call
in libusb should perform the same function.

[l***@jumpstation.co.uk]

<snip />

Post by Tim Roberts
RESET_PIPE asks the host controller to reset its understanding of the
endpoint's state back to the initial conditions. The usb_resetep call
in libusb should perform the same function.

in LibUSB v0.1 the usb_resetep function is depreciated in favor of
usb_clear_halt.
Should I still use usb_resetep ?
and do you think I need to call it separately four times to match the trace I
was getting in snoopyPro ?

thanks

Rob

[Tim Roberts]

Post by l***@jumpstation.co.uk
<snip />

Post by Tim Roberts
RESET_PIPE asks the host controller to reset its understanding of the
endpoint's state back to the initial conditions. The usb_resetep call
in libusb should perform the same function.

in LibUSB v0.1 the usb_resetep function is depreciated...

That's "deprecated", perhaps the most commonly misspelled word in
technical jargon, because "depreciated" usually makes almost as much
sense in context.

Post by l***@jumpstation.co.uk
...in favor of usb_clear_halt.
Should I still use usb_resetep ?

There's no single answer. You shouldn't need EITHER of them. These are
both designed to recover from an error condition. Unless you know the
endpoint is in an error condition, you shouldn't need them at all.

Post by l***@jumpstation.co.uk
and do you think I need to call it separately four times to match the trace I
was getting in snoopyPro ?

That's superstition and voodoo. It's like pushing the crosswalk
button. If once is good, ten times must be better.

[l***@jumpstation.co.uk]

hi,

I have a Linux libusb C program that generates URBs based on files captured in
Windows with snoopypro.
When executing the program the required function (Delete all files) is
completed on the device but then the device is left in a strange state
different from when the original Windows software is used.(* details after
post)
Unplugging and replugging the device sets it right but I can not work out what
I am doing wrong.
I have run diff against the set of URBs from the snoopypro capture and what my
program thinks it is generating, I have introduced delays to try an more
closely match the original and I have swapped the usb_close(usb_handle); call
to a usb_reset(usb_handle); all to no avail.

If you remember a while back I was asking here about generating ABORT and
RESET URBs I tried various suggestions but none appear to be affecting the
device.

Is there anything else I am missing?

Is there a more complete way to reset the device so it acts as if it was
unplugged and replugged ?

Regards

Rob

* device is a digital keyring showing small images.
When using the Windows software images are deleted and a message appears on
the device "No Image".
When my program is run device shows the original image it held and 22 blank
images if scrolled. Unplugging and replugging the device gives the
correct "No Image" message.

[Bertrik Sikken]

Post by l***@jumpstation.co.uk
I have a Linux libusb C program that generates URBs based on files captured in
Windows with snoopypro.
When executing the program the required function (Delete all files) is
completed on the device but then the device is left in a strange state
different from when the original Windows software is used.(* details after
post)
Unplugging and replugging the device sets it right but I can not work out what
I am doing wrong.
I have run diff against the set of URBs from the snoopypro capture and what my
program thinks it is generating, I have introduced delays to try an more
closely match the original and I have swapped the usb_close(usb_handle); call
to a usb_reset(usb_handle); all to no avail.
If you remember a while back I was asking here about generating ABORT and
RESET URBs I tried various suggestions but none appear to be affecting the
device.
Is there anything else I am missing?

I can imagine that the protocol has commands that poll the status
of the device and requires the program on the PC to wait until a
certain status code is returned. Simply replaying commands will
not work then.

If I would have to make the device work, I would try to look deeper
into the protocol. Status polls should be easily recogniseable
because they repeat a lot. If you can put the logs up somewhere, I
won't mind taking a look and have a guess at the protocol.

Kind regards,
Bertrik

[l***@jumpstation.co.uk]

Drat, I am not being very clear.

Post by Bertrik Sikken
I can imagine that the protocol has commands that poll the status
of the device and requires the program on the PC to wait until a
certain status code is returned. Simply replaying commands will
not work then.
Kind regards,
Bertrik

My program is 'hand written' as opposed to automatically generated and does
emulate the status polls required.
If I take a text dump of the original capture (only line per URB) and compare
with the log data generated from a run of my program then the only
inconsistencies are status poll loop lengths and they are extremely simular.

Post by Bertrik Sikken
You really mean snoopypro and not usbsnoop 1.8? Last time I checked
the log file format was not compatible :-(
best regards,
Timo Lindfors

I hacked snoopypro to dump better XML and clearer text files (pending access
to sourceforge to commit changes) I also wrote various bash scripts and C#
code to 'shape' log files.

As far as I can reasonably see the URBs that were generated and captured in
Windows with snoopypro are the same as those I have generated, bar the ABORT
and RESETs.
I know I am pretty close as all the return codes in the protocol are matching
where I have made mistakes in the past the return codes are clearly noting
protocol inconsistencies.

If I could just force a hardware reset of the device then it would return the
correct state.

Until this issue is resolved I am not happy to continue working on the devices
other function (upload image).

Any clues welcome.

Thanks

Rob

[Peter Stuge]

Post by l***@jumpstation.co.uk
If I could just force a hardware reset of the device then it would
return the correct state.

The only comment I can offer is that a hardware reset really should
not be neccessary to "commit" the delete operations. If it is indeed
then I think the device is plain broken.

I know that doesn't help you at all though. Sorry. :\


//Peter

[l***@jumpstation.co.uk]

hi,

To further test my Linux based usblib application I installed cygwin in
windows and with no changes built my program. Installed the win32 usblib
filter into windows and the app ran found the device and seemed to work in
exactly the same was as in Linux.

Setup snoopypro, reinstalled all the services etc and restarted the device,
immediately get the EP0 announcments captured in snoopypro.
Ran my program from the cygwin shell and no packets are captured even though
the device was responding correctly.

I guess this is because the the win32 usblib filter and the snoopypro filter
are not seeing each other due to windows architecture (i am using XP sp2).

Is there a fix to make the win32 usblib filter visible to snoopypro?

Would it help to install the win32 driver and set it up for the device
overriding the standard windows driver?

Is there another capture program for windows that works with data travelling
across the win32 usblib?

Thanks Rob

[Timo Lindfors]

Hi,

Post by l***@jumpstation.co.uk
I have a Linux libusb C program that generates URBs based on files captured in
Windows with snoopypro.

You really mean snoopypro and not usbsnoop 1.8? Last time I checked
the log file format was not compatible :-(

best regards,
Timo Lindfors