Bug 209411

On Sun, Sep 27, 2020 at 05:51:20PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=209411
> 
>             Bug ID: 209411
>            Summary: When retrieving string descriptor from mobile device
>                     returns eproto error
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 4.19
>           Hardware: All
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: USB
>           Assignee: drivers_usb@kernel-bugs.kernel.org
>           Reporter: rachithas104@gmail.com
>         Regression: No
> 
> I am trying to get get string descriptor from mobile phone,however when
> trying
> to retrieve one particular index it returns EPROTO,
> 
> dev->fd, USB_DIR_IN,USB_REQ_GET_DESCRIPTOR,DESCRIPT_STRING * 256 + index,     
>                                               languageid, sizeof buf, buf);
> 
> Return value is -1 for  ioctl(fd, USBDEVFS_CONTROL, &ioctl_ctrl);
> 
> kernel: [ 7084.327097] usb 1-1.2: reset high-speed USB device number 12 using
> ehci-pci
> kernel: [ 7084.831056] usb 1-1.2: device not accepting address 12, error -71
> kernel: [ 7085.119075] usb 1-1.2: reset high-speed USB device number 12 using
> ehci-pci
>  kernel: [ 7085.431054] usb 1-1.2: reset high-speed USB device number 12
>  using
> ehci-pci
> [ 7085.935069] usb 1-1.2: device not accepting address 12, error -71
> [ 7086.227132] usb 1-1.2: reset high-speed USB device number 12 using
> ehci-pci
> S[ 7087.321929] usb 1-1.2: usbfs: USBDEVFS_CONTROL failed cmd ctxusb rqt 128
> rq
> 6 len 255 ret -71
>   kernel: [ 7087.607093] usb 1-1.2: reset high-speed USB device number 12
>   using
> ehci-pci
> 
> My URB request and without my program in picture request is same

Not all strings are readable from the device, are you sure that is a
valid string descriptor index to be requesting?

(In reply to Greg Kroah-Hartman from comment #1)
> On Sun, Sep 27, 2020 at 05:51:20PM +0000,
> bugzilla-daemon@bugzilla.kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=209411
> > 
> >             Bug ID: 209411
> >            Summary: When retrieving string descriptor from mobile device
> >                     returns eproto error
> >            Product: Drivers
> >            Version: 2.5
> >     Kernel Version: 4.19
> >           Hardware: All
> >                 OS: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: USB
> >           Assignee: drivers_usb@kernel-bugs.kernel.org
> >           Reporter: rachithas104@gmail.com
> >         Regression: No
> > 
> > I am trying to get get string descriptor from mobile phone,however when
> > trying
> > to retrieve one particular index it returns EPROTO,
> > 
> > dev->fd, USB_DIR_IN,USB_REQ_GET_DESCRIPTOR,DESCRIPT_STRING * 256 + index,   
> >                                               languageid, sizeof buf, buf);
> > 
> > Return value is -1 for  ioctl(fd, USBDEVFS_CONTROL, &ioctl_ctrl);
> > 
> > kernel: [ 7084.327097] usb 1-1.2: reset high-speed USB device number 12
> using
> > ehci-pci
> > kernel: [ 7084.831056] usb 1-1.2: device not accepting address 12, error
> -71
> > kernel: [ 7085.119075] usb 1-1.2: reset high-speed USB device number 12
> using
> > ehci-pci
> >  kernel: [ 7085.431054] usb 1-1.2: reset high-speed USB device number 12
> >  using
> > ehci-pci
> > [ 7085.935069] usb 1-1.2: device not accepting address 12, error -71
> > [ 7086.227132] usb 1-1.2: reset high-speed USB device number 12 using
> > ehci-pci
> > S[ 7087.321929] usb 1-1.2: usbfs: USBDEVFS_CONTROL failed cmd ctxusb rqt
> 128
> > rq
> > 6 len 255 ret -71
> >   kernel: [ 7087.607093] usb 1-1.2: reset high-speed USB device number 12
> >   using
> > ehci-pci
> > 
> > My URB request and without my program in picture request is same
> 
> Not all strings are readable from the device, are you sure that is a
> valid string descriptor index to be requesting?

Yes its valid string,

Also happening only when ioctl(fd, USBDEVFS_SETCONFIGURATION, &configuration ) is called before getting string descriptors

Maybe the mobile phone just doesn't want to send its string descriptors after the configuration has been set.  In any case, it seems like you have found a usable workaround for the problem.

If you want to get more information about what's happening, you can use usbmon to trace the packets getting sent and received both during enumeration and while your program is running (see Documentation/usb/usbmon.rst in the kernel source).

Mobile phone having kernel version 4.14 works

(In reply to Alan Stern from comment #4)
> Maybe the mobile phone just doesn't want to send its string descriptors
> after the configuration has been set.  In any case, it seems like you have
> found a usable workaround for the problem.
> 
> If you want to get more information about what's happening, you can use
> usbmon to trace the packets getting sent and received both during
> enumeration and while your program is running (see
> Documentation/usb/usbmon.rst in the kernel source).

Even reset fails with same error 71

So make a usbmon trace with a 4.14 kernel and a trace with a 4.19 kernel, and compare them to see where they are different.  That should indicate where the problem is.

Created attachment 292725 [details]
Non working usbmon traces in ptp mode

Hi I have attached usbmon traces of non working device in ptp mode ,reset call fails with this device

Created attachment 292727 [details]
Working device in ptp mode

Here reset succeeds

(In reply to Alan Stern from comment #7)
> So make a usbmon trace with a 4.14 kernel and a trace with a 4.19 kernel,
> and compare them to see where they are different.  That should indicate
> where the problem is.

Can you help in checking parallely usbmon traces

The traces aren't really complete, because you didn't start them until after the USB cable was plugged in.  Also, the traces start out with the computer reading string descriptors 1, 2, 3, 4, and 6 (in the non-working trace), and the values of the descriptors are different in the two traces.  In the working trace, the values are:

  1: "Xiaomi"
  2: "MI MAX"
  3: "d553b4b6"
  4: "ADB Interface"

In the non-working trace:

  1: "Xiaomi"
  2: "Redmi K30 5G"
  3: "c2a85d7"
  4: "ptp_adb"
  6: "ADB Interface"

It looks like you used two different phones for the tests, or one phone with two different ROMs installed.  Is that what you did?

Are you asking why one phone works and the other phone doesn't?

(In reply to Alan Stern from comment #11)
> The traces aren't really complete, because you didn't start them until after
> the USB cable was plugged in.  Also, the traces start out with the computer
> reading string descriptors 1, 2, 3, 4, and 6 (in the non-working trace), and
> the values of the descriptors are different in the two traces.  In the
> working trace, the values are:
> 
>   1: "Xiaomi"
>   2: "MI MAX"
>   3: "d553b4b6"
>   4: "ADB Interface"
> 
> In the non-working trace:
> 
>   1: "Xiaomi"
>   2: "Redmi K30 5G"
>   3: "c2a85d7"
>   4: "ptp_adb"
>   6: "ADB Interface"
> 
> It looks like you used two different phones for the tests, or one phone with
> two different ROMs installed.  Is that what you did?
> 
> Are you asking why one phone works and the other phone doesn't?

Yes Mi Max works ,Redmi doesn't. The traces were taken after  I have plugged the device and changed it to PTP mode
Mainly the traces has info when my program starts enumerating. Can I know is there any tool you used to get this info

My program issues reset command, it works with MiMax ,but fails with other device

You can get the descriptor values by running "lsusb -v".

If the phone fails when you reset it, you should change your program.  Don't issue the reset command!

Why did you open this bug report in the first place?

(In reply to Alan Stern from comment #14)
> You can get the descriptor values by running "lsusb -v".
> 
> If the phone fails when you reset it, you should change your program.  Don't
> issue the reset command!
> 
> Why did you open this bug report in the first place?

Since the device with 4.14 kernel works and 4.19 fails,I opened whether there is any protocol change ,so that I can change my program accrordingly,I am seeing this in syslog when issued reset command
kernel: [85237.846504] usb 1-1.2: reset high-speed USB device number 19 using ehci-pci
 kernel: [85238.146480] usb 1-1.2: device descriptor read/64, error -71
 kernel: [85238.558551] usb 1-1.2: reset high-speed USB device number 19 using ehci-pci
kernel: [85239.062496] usb 1-1.2: device not accepting address 19, error -71
kernel: [85239.350498] usb 1-1.2: reset high-speed USB device number 19 using ehci-pci
 kernel: [85240.544425] usb 1-1.2: usbfs: USBDEVFS_CONTROL failed cmd ctxusb rqt 128 rq 6 len 255 ret -71
0 kernel: [85240.838479] usb 1-1.2: reset high-speed USB device number 19 using ehci-pci

You would have to ask the people who created those kernels for the phones.  Android devices use specialized kernels, not the same ones that we develop here.

If you want to avoid getting these errors, just change your program so that it doesn't issue the reset command.

(In reply to Alan Stern from comment #16)
> You would have to ask the people who created those kernels for the phones. 
> Android devices use specialized kernels, not the same ones that we develop
> here.
> 
> If you want to avoid getting these errors, just change your program so that
> it doesn't issue the reset command.


OK which tool can be used to analyze usbmon traces

You can use Wireshark to collect and analyze the traces.  Wireshark understands about usbmon and will use it automatically.

(In reply to Alan Stern from comment #18)
> You can use Wireshark to collect and analyze the traces.  Wireshark
> understands about usbmon and will use it automatically.

Thanks

WHen you're happy with the results of your testing, you can go ahead and close out this bug report.

(In reply to Alan Stern from comment #20)
> WHen you're happy with the results of your testing, you can go ahead and
> close out this bug report.

Can you suggest how to avoid EPROTO error even after calling Select Configuration

(In reply to Alan Stern from comment #20)
> WHen you're happy with the results of your testing, you can go ahead and
> close out this bug repor
(In reply to Alan Stern from comment #20)
> WHen you're happy with the results of your testing, you can go ahead and
> close out this bug report.

Currently while String Descriptor is getting retrieved for index 4 it results in EPROTO error

As far as I can tell, both of these errors are caused by bugs in the phone's software.  Changing your program isn't likely to help.

I (In reply to Alan Stern from comment #23)
> As far as I can tell, both of these errors are caused by bugs in the phone's
> software.  Changing your program isn't likely to help.
I checked wireshark traces without my software same request of SetConfiguration is called and there is no difference in packets with and without my software in picture

If your software isn't running, then what software issues the Get-String-Descriptor request for string descriptor 4 that causes the EPROTO error?

If the same packets are present with or without your software, then your software isn't sending any packets.  Is this really what you mean?

In any case, the EPROTO error is caused by the code running on the phone.  I can't give you much advice about that.

When my software dont call setconfiguration there is no protocol error
Protocol error happens when my software calls setconfig and tries to retrieve index 4

(In reply to Alan Stern from comment #25)
> If your software isn't running, then what software issues the
> Get-String-Descriptor request for string descriptor 4 that causes the EPROTO
> error?
> 
> If the same packets are present with or without your software, then your
> software isn't sending any packets.  Is this really what you mean?
> 
> In any case, the EPROTO error is caused by the code running on the phone.  I
> can't give you much advice about that.

Also bus reset is happening when I call selectconfiguration from my app

(In reply to Alan Stern from comment #25)
> If your software isn't running, then what software issues the
> Get-String-Descriptor request for string descriptor 4 that causes the EPROTO
> error?
> 
> If the same packets are present with or without your software, then your
> software isn't sending any packets.  Is this really what you mean?
> 
> In any case, the EPROTO error is caused by the code running on the phone.  I
> can't give you much advice about that.

Hello I see similar thread which you have fixed https://www.spinics.net/lists/linux-usb/msg199677.html
I also see the same problem when calling setconfiguration
How can I test the fix mentioned in thread,can you kindly help

That fix is part of the linux-next repository, and it will be included in the release of kernel version 5.10 about 3 months from now.

If you don't want to wait that long, you'll have to build your own kernel.  It's an involved process, not difficult but time-consuming.  I don't want to explain all the details here; there are plenty of guides available on the web describing how to build and test kernels.  In fact, the web site for your Linux distribution probably has something that shows how to do this.

(In reply to Alan Stern from comment #29)
> That fix is part of the linux-next repository, and it will be included in
> the release of kernel version 5.10 about 3 months from now.
> 
> If you don't want to wait that long, you'll have to build your own kernel. 
> It's an involved process, not difficult but time-consuming.  I don't want to
> explain all the details here; there are plenty of guides available on the
> web describing how to build and test kernels.  In fact, the web site for
> your Linux distribution probably has something that shows how to do this.

Should mobile kernel version be upgraded or Ubuntu's kernel to consume the fix?

Also do you think my issue is similar to the other issue? I read through description,is there any additional logs should I provide to confirm if its same?

The fix you mentioned in comment #28 applies to the Ubuntu (host) kernel.

As to whether it will fix your EPROTO problem...  I'm not certain, but there's a good chance that it will.  However, I don't think it will help with the device reset failures.

(In reply to Alan Stern from comment #32)
> The fix you mentioned in comment #28 applies to the Ubuntu (host) kernel.
> 
> As to whether it will fix your EPROTO problem...  I'm not certain, but
> there's a good chance that it will.  However, I don't think it will help
> with the device reset failures.

Any workaround for now other than not calling SelectConfiguration?

(In reply to Alan Stern from comment #32)
> The fix you mentioned in comment #28 applies to the Ubuntu (host) kernel.
> 
> As to whether it will fix your EPROTO problem...  I'm not certain, but
> there's a good chance that it will.  However, I don't think it will help
> with the device reset failures.

Any workaround for now other than not calling SelectConfiguration?

Come to think of it, that particular change probably _won't_ affect your Get-String-Descriptor call.  It only affects bulk and interrupt endpoints, not control or isochronous endpoints, and Get-String-Descriptor uses endpoint 0 (which is a control endpoint).

Not calling Set-Config seems like the best workaround.  Is there any reason why your program calls it in the first place?  Isn't the device already using the configuration you want?

R(In reply to Alan Stern from comment #35)
> Come to think of it, that particular change probably _won't_ affect your
> Get-String-Descriptor call.  It only affects bulk and interrupt endpoints,
> not control or isochronous endpoints, and Get-String-Descriptor uses
> endpoint 0 (which is a control endpoint).
> 
> Not calling Set-Config seems like the best workaround.  Is there any reason
> why your program calls it in the first place?  Isn't the device already
> using the configuration you want?

Regarding Get-String descriptor call,the problem seems to be happening only when I call SelectConfiguration.If we skip SelectConfiguration there is no error
So I am thinking SelectConfiguration call is making device to go to undesired state ,its causing bus reset
We are calling SelectConfiguration as per the specification
Same program works with mobile device which had 4.14 kernel version even on calling SelectConfiguration
Is there any log which would give more info on what actually is happening to the device on calling Selectonfiguration
I am sure SelectConfiguration is doing something to the device,however no logs are helping much

(In reply to Alan Stern from comment #35)
> Come to think of it, that particular change probably _won't_ affect your
> Get-String-Descriptor call.  It only affects bulk and interrupt endpoints,
> not control or isochronous endpoints, and Get-String-Descriptor uses
> endpoint 0 (which is a control endpoint).
> 
> Not calling Set-Config seems like the best workaround.  Is there any reason
> why your program calls it in the first place?  Isn't the device already
> using the configuration you want?

I also see when Set-Config is called from Windows device there is no issue

\Is there any way to find out exactly what Windows sends to the device?  Maybe it's different from what your program sends.

Keep in mind also that the kernel sends a Set-Config request to the device when you plug it into the computer.  That request doesn't appear to cause problems either.

The only logs which might give you more information about what's happening on the device are the device's own logs.  Maybe you can learn something, for example, by running dmesg in a terminal app on the device.

(In reply to Alan Stern from comment #38)
> \Is there any way to find out exactly what Windows sends to the device? 
> Maybe it's different from what your program sends.
> 
> Keep in mind also that the kernel sends a Set-Config request to the device
> when you plug it into the computer.  That request doesn't appear to cause
> problems either.
> 
> The only logs which might give you more information about what's happening
> on the device are the device's own logs.  Maybe you can learn something, for
> example, by running dmesg in a terminal app on the device.

Keep in mind also that the kernel sends a Set-Config request to the device when you plug it into the computer.  That request doesn't appear to cause problems either-This doesn't cause problem when the kernel first sends set-config,only problem happens when there is one more select-config call on the same device

Its happening only with mobile,other devices are working fine

(In reply to rachithas104 from comment #37)

> I also see when Set-Config is called from Windows device there is no issue

That may be because Windows apparently does not go directly to a new configuration, it first goes to config #0 and waits a while to let the device reset its config, then selects the new config.

(In reply to Lars Melin from comment #40)
> (In reply to rachithas104 from comment #37)
> 
> > I also see when Set-Config is called from Windows device there is no issue
> 
> That may be because Windows apparently does not go directly to a new
> configuration, it first goes to config #0 and waits a while to let the
> device reset its config, then selects the new config.

I have compared wireshark usb traces,calls are similar

It won't take you long to change your program to select config#0, wait 100mS, then select the intended config in order to test if that is the problem.

(In reply to Lars Melin from comment #42)
> It won't take you long to change your program to select config#0, wait
> 100mS, then select the intended config in order to test if that is the
> problem.

T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=102 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=2717 ProdID=ff18 Rev= 4.19
S:  Manufacturer=Xiaomi
S:  Product=Redmi 
S:  SerialNumber=c2a85d9
C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver=usbfs
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) Atr=03(Int.) MxPS=  28 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms


There is only one configuration

(In reply to rachithas104 from comment #43)
 
> There is only one configuration

So why do you then select configuration when the configuration descriptor tells you that there is only one?

You have a 'user space driver' attached to the PTP interface, are you running under a virtual machine or what is that driver?

(In reply to Lars Melin from comment #44)
> (In reply to rachithas104 from comment #43)
>  
> > There is only one configuration
> 
> So why do you then select configuration when the configuration descriptor
> tells you that there is only one?
> 
> You have a 'user space driver' attached to the PTP interface, are you
> running under a virtual machine or what is that driver?
I am selecting the config as per spec, I am running in Ubuntu laptop and I have user space driver

(In reply to Lars Melin from comment #44)
> (In reply to rachithas104 from comment #43)
>  
> > There is only one configuration
> 
> So why do you then select configuration when the configuration descriptor
> tells you that there is only one?
> 
> You have a 'user space driver' attached to the PTP interface, are you
> running under a virtual machine or what is that driver?

It works with this device having low kernel version
Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=100 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=2717 ProdID=ff18 Rev= 3.10
S:  Manufacturer=Xiaomi
S:  Product=MI 
S:  SerialNumber=d553b4b6
C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver=usbfs
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) Atr=03(Int.) MxPS=  28 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

(In reply to Lars Melin from comment #44)
> (In reply to rachithas104 from comment #43)
>  
> > There is only one configuration
> 
> So why do you then select configuration when the configuration descriptor
> tells you that there is only one?
> 
> You have a 'user space driver' attached to the PTP interface, are you
> running under a virtual machine or what is that driver?

Also I see when submiting URB's to endpoint OX81 is resulting in failure
I dont see signal gets reaped

Created attachment 292945 [details]
device in ptp mode without calling SelectConfiguration

device in ptp mode without calling SelectConfiguration

Created attachment 292947 [details]
device in ptp mode  calling SelectConfiguration

device in ptp mode  calling SelectConfiguration

(In reply to Lars Melin from comment #44)
> (In reply to rachithas104 from comment #43)
>  
> > There is only one configuration
> 
> So why do you then select configuration when the configuration descriptor
> tells you that there is only one?
> 
> You have a 'user space driver' attached to the PTP interface, are you
> running under a virtual machine or what is that driver?

I have attached traces when I am trying to enumerate mobile device in PTP mode 
Working-without calling SelectConfiguration
Non-working -calling SelectConfiguration

(In reply to Lars Melin from comment #44)
> (In reply to rachithas104 from comment #43)
>  
> > There is only one configuration
> 
> So why do you then select configuration when the configuration descriptor
> tells you that there is only one?
> 
> You have a 'user space driver' attached to the PTP interface, are you
> running under a virtual machine or what is that driver?

Can you kindly help

(In reply to Lars Melin from comment #42)
> It won't take you long to change your program to select config#0, wait
> 100mS, then select the intended config in order to test if that is the
> problem.

Tried this but still same results

The nonworking trace doesn't show any errors.  In fact, it looks almost exactly the same as the working trace, except that it has a Set-Config request and it ends earlier.

Since your program works when it doesn't issue the Set-Config request, why not simply avoid doing that?

(In reply to Alan Stern from comment #53)
> The nonworking trace doesn't show any errors.  In fact, it looks almost
> exactly the same as the working trace, except that it has a Set-Config
> request and it ends earlier.
> 
> Since your program works when it doesn't issue the Set-Config request, why
> not simply avoid doing that?

Correct non working trace doesn't show any errors,thats the reason wanted to know what is happening internally,it is happening with most Android phones,whereas some phones work.
I can avoid set-config request,but just wanted to know more why this has started happening,Since with all device we call Select-Configuration and it works fine

Sorry, I don't think anybody reading this bug report knows what's happening on your phone.  We don't even know what software is running on the phone; Android is different from ordinary Linux.

You should try asking the people who made the phone.