Re: [libusb] Device changing serial numbers

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

First, thank you Alan. 

Second, addressing your question: yes, transfers using the old device handle succeed. This includes flashing and verifying the bootrom. 

Is it possible that if the device serial number changes without resetting the device we get a "partial" enumeration, or does libusb handle triggering the requisite events if a device randomly changes its serial number and doesn't inform the system?

============================================================
 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
  Original Message  
From: Alan Stern
Sent: Tuesday, September 1, 2015 7:25 AM
To: Matthew Giassa
Cc: Libusb Mailing List
Subject: Re: [libusb] Device changing serial numbers

On Tue, 1 Sep 2015, Matthew Giassa wrote:

> I'm working with a pair of USB2.0 cameras that exhibit some interesting 
> behavior. The cameras work fine under normal circumstances, any my test 
> app is able to communicate with them, query extended data from bootrom 
> with a proprietary protocol, etc.
> 
> When I want to do a firmware update of the camera though, I've noticed 
> that it changes the device serial number (the one which I see from the 
> perspective of libusb, or when I query the device list via "lsusb -v"), 
> from the actual serial number, to a placeholder serial number 
> (0xDEADBEEF). My guess is that this is so the typically used video 
> recording application won't enumerate the device, but the updater 
> software will know that it's a device in "updater mode" if it has a 
> matching vendor ID (VID) and that specific serial number.
> 
> Prior to the update, the device has the following properties:
> Bus: 6
> Addr: 10
> Serial: 0x1234ABCD
> 
> When I put the device in "updater mode", that changes to:
> Bus: 6
> Addr: 11
> Serial: 0xDEADBEEF
> 
> What strikes me as odd is the following:
> 1) I can query the bootrom on the "new" device (6, 11, 0xDEADBEEF), and 
> get valid device information (ie: query special registers for the "true" 
> serial number of the device, 0x1234ABCD).
> 2) I can also query the "old" device (ie: 6, 10, 0x1234ABCD) if I leave 
> the libusb_device handle open, even though the device no longer 
> enumerates with the old serial/bus/addr combination.

What do you mean by this? If you send a transfer through the old
device handle, it ought to fail.

Are you saying that transfers using the old handle can succeed? Or are 
you merely saying that certain queries which don't involve actually
communicating with the device can succeed? There's a big difference.

> It's to my understanding that whenever a device is re-enumerated after a 
> disconnect/reconnect even, the "ADDR" field will be incremented for all 
> future device connections. I learned this in a previous thread where a 
> libusb contributer advised me not to rely on bus/addr as a unique key 
> pair to identify devices.

That's right.

> To the questions:
> 1) Should the old device connection (6, 10, 0x1234ABCD) still be valid 
> if it no longer enumerates?

It should not be valid. But some operations using the old handle may 
continue to work until the handle is closed.

> 2) Is there any reason libusb should/shouldn't invalidate the open 
> handle to the device?

No reason -- libusb _should_ realize the old handle is no longer 
connected to anything. It may take some time for this to happen, 
however. And it may depend on how you have libusb configured.

> 3) Is it reasonable to ever expect libusb to allow data transfer via a 
> device handle for which the device is no longer "present"?

It certainly is not reasonable to expect such a data transfer to
_succeed_. On the other hand, libusb may not do anything to prevent
you from making the attempt; you shouldn't depend on libusb to stop 
you.

> 4) From libusb's perspective, is this "reasonable" behavior for a
> device serial to change during operation?

It is not reasonable for a serial number to change without a 
re-enumeration. But a change with a re-enumeration is perfectly 
reasonable.

Alan Stern