Re: [libusb] Device changing serial numbers

[Alan S. <st...@ro...>]

On Tue, 1 Sep 2015, Matthew Giassa wrote:

> > Matthew Giassa wrote:
> >> Second, addressing your question: yes, transfers using the old device handle succeed. This includes flashing and verifying the bootrom.
> >
> > This is impossible to believe.  The device number is the physical
> > addressing mechanism on the bus.  If the device is now known as device
> > 11, then requests to device 10 will be ignored.
> >
> > You did say you are working with two cameras.  Isn't it possible you are
> > getting confused between the two cameras here?  Do both cameras use the
> > same serial number?  (Windows, for what it's worth, will not allow that
> > situation  VID/PID/Serial must be unique system-wide.)
> 
> I should clarify the details. I'm working with a single camera. During 
> normal operation, let's assume it has a serial number of "ABCDEFGH". 
> When I trigger it to enter the firmware update mode, I see two cameras 
> for a short while, with serial numbers of:
> Device 0:
>    Serial: 1234ABCD

Is this supposed to be different from the "ABCDEFGH" you mentioned 
above?

>    Bus: 6
>    Addr: 10
> Device 1:
>    Serial: DEADBEEF
>    Bus: 6
>    Addr: 11
> 
> A short while later, the first device disappears, and my list becomes:
> Device 0:
>    Serial: DEADBEEF
>    Bus: 6
>    Addr: 11
> 
> I know it sounds strange, but I re-tested and confirmed today: I am 
> still able to write to the "old" device with serial number "1234ABCD" by 
> using the (now-stale) libusb_device handle to it.
> 
> I can communicate with the "new" device (serial "DEADBEEF") as well (ie: 
> query value from bootrom, etc), but I can't seem to tell the firmware 
> updater to talk to the "new" device: it seems intent on using the 
> "stale" device handle until all operations complete.
> 
> Would it be reasonable to expect this behavior won't work in future 
> releases of libusb?

It would be reasonable to expect this behavior won't work in _any_
release of libusb!  :-)

Please try the following experiment.  Before running the test, do (as 
root):

	dmesg -c >/dev/null
	echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
	echo 1 >/sys/module/usbcore/parameters/usbfs_snoop

This will cause a bunch of debugging output to be added to the kernel 
log whenever libusb talks to the kernel or other interesting events 
happen.

Then after the test, run the "dmesg" command and post the output for us 
to look at.

Alan Stern