Bug 209411 - When retrieving string descriptor from mobile device returns eproto error
Summary: When retrieving string descriptor from mobile device returns eproto error
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Default virtual assignee for Drivers/USB
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-27 17:51 UTC by rachithas104
Modified: 2020-10-14 18:56 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.19
Tree: Mainline
Regression: No


Attachments
Non working usbmon traces in ptp mode (231.88 KB, text/plain)
2020-09-30 11:05 UTC, rachithas104
Details
Working device in ptp mode (17.68 KB, text/plain)
2020-09-30 11:06 UTC, rachithas104
Details
device in ptp mode without calling SelectConfiguration (52.06 KB, application/octet-stream)
2020-10-13 17:55 UTC, rachithas104
Details
device in ptp mode calling SelectConfiguration (10.38 KB, application/octet-stream)
2020-10-13 17:56 UTC, rachithas104
Details

Description rachithas104 2020-09-27 17:51:20 UTC
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
Comment 1 Greg Kroah-Hartman 2020-09-28 17:49:42 UTC
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?
Comment 2 rachithas104 2020-09-29 14:35:38 UTC
(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,
Comment 3 rachithas104 2020-09-29 14:38:14 UTC
Also happening only when ioctl(fd, USBDEVFS_SETCONFIGURATION, &configuration ) is called before getting string descriptors
Comment 4 Alan Stern 2020-09-29 16:04:58 UTC
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).
Comment 5 rachithas104 2020-09-29 16:23:49 UTC
Mobile phone having kernel version 4.14 works
Comment 6 rachithas104 2020-09-29 16:24:11 UTC
(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
Comment 7 Alan Stern 2020-09-29 16:40:04 UTC
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.
Comment 8 rachithas104 2020-09-30 11:05:07 UTC
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
Comment 9 rachithas104 2020-09-30 11:06:26 UTC
Created attachment 292727 [details]
Working device in ptp mode

Here reset succeeds
Comment 10 rachithas104 2020-09-30 11:06:57 UTC
(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
Comment 11 Alan Stern 2020-09-30 14:47:58 UTC
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?
Comment 12 rachithas104 2020-09-30 14:52:21 UTC
(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
Comment 13 rachithas104 2020-09-30 14:53:20 UTC
My program issues reset command, it works with MiMax ,but fails with other device
Comment 14 Alan Stern 2020-09-30 15:04:54 UTC
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?
Comment 15 rachithas104 2020-09-30 15:15:13 UTC
(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
Comment 16 Alan Stern 2020-09-30 15:37:06 UTC
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.
Comment 17 rachithas104 2020-09-30 15:41:47 UTC
(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
Comment 18 Alan Stern 2020-09-30 15:43:22 UTC
You can use Wireshark to collect and analyze the traces.  Wireshark understands about usbmon and will use it automatically.
Comment 19 rachithas104 2020-09-30 15:44:23 UTC
(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
Comment 20 Alan Stern 2020-09-30 19:25:05 UTC
WHen you're happy with the results of your testing, you can go ahead and close out this bug report.
Comment 21 rachithas104 2020-10-02 16:02:44 UTC
(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
Comment 22 rachithas104 2020-10-02 16:04:17 UTC
(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
Comment 23 Alan Stern 2020-10-02 16:46:53 UTC
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.
Comment 24 rachithas104 2020-10-05 13:53:57 UTC
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
Comment 25 Alan Stern 2020-10-05 14:38:10 UTC
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.
Comment 26 rachithas104 2020-10-05 14:48:35 UTC
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
Comment 27 rachithas104 2020-10-07 04:54:40 UTC
(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
Comment 28 rachithas104 2020-10-10 18:02:47 UTC
(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
Comment 29 Alan Stern 2020-10-11 01:15:14 UTC
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.
Comment 30 rachithas104 2020-10-11 04:27:14 UTC
(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?
Comment 31 rachithas104 2020-10-11 08:13:13 UTC
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?
Comment 32 Alan Stern 2020-10-11 14:13:15 UTC
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.
Comment 33 rachithas104 2020-10-12 12:49:32 UTC
(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?
Comment 34 rachithas104 2020-10-12 12:50:10 UTC
(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?
Comment 35 Alan Stern 2020-10-12 14:47:39 UTC
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?
Comment 36 rachithas104 2020-10-12 16:25:28 UTC
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
Comment 37 rachithas104 2020-10-12 16:49:20 UTC
(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
Comment 38 Alan Stern 2020-10-12 18:30:25 UTC
\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.
Comment 39 rachithas104 2020-10-12 18:50:18 UTC
(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
Comment 40 Lars Melin 2020-10-13 00:24:16 UTC
(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.
Comment 41 rachithas104 2020-10-13 04:09:35 UTC
(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
Comment 42 Lars Melin 2020-10-13 05:10:15 UTC
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.
Comment 43 rachithas104 2020-10-13 06:02:40 UTC
(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
Comment 44 Lars Melin 2020-10-13 06:21:10 UTC
(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?
Comment 45 rachithas104 2020-10-13 06:25:57 UTC
(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
Comment 46 rachithas104 2020-10-13 06:37:16 UTC
(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
Comment 47 rachithas104 2020-10-13 17:51:30 UTC
(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
Comment 48 rachithas104 2020-10-13 17:55:51 UTC
Created attachment 292945 [details]
device in ptp mode without calling SelectConfiguration

device in ptp mode without calling SelectConfiguration
Comment 49 rachithas104 2020-10-13 17:56:39 UTC
Created attachment 292947 [details]
device in ptp mode  calling SelectConfiguration

device in ptp mode  calling SelectConfiguration
Comment 50 rachithas104 2020-10-13 17:58:19 UTC
(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
Comment 51 rachithas104 2020-10-14 03:56:05 UTC
(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
Comment 52 rachithas104 2020-10-14 13:24:11 UTC
(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
Comment 53 Alan Stern 2020-10-14 18:43:57 UTC
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?
Comment 54 rachithas104 2020-10-14 18:49:17 UTC
(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
Comment 55 Alan Stern 2020-10-14 18:56:31 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.