Re: [libusb] Device changing serial numbers

[Matthew G. <ma...@gi...>]

 >> 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

My mistake. That was a separate camera with a serial of "ABCDEFGH". The 
one I'm currently using has a serial of "1234ABCD". Both of them have 
serial numbers of "DEADBEEF" when in Firmware update mode.

I'll general the logs as advised and post them shortly.

Thanks!

============================================================
Matthew Giassa, MASc, MIEEE, EIT
Security, Embedded Systems and DSP Specialist
linkedin: https://ca.linkedin.com/in/giassa
e-mail:   ma...@gi...
website:  www.giassa.net

On 09/02/15 07:16, Alan Stern wrote:
> 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
>