This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 840541 - libmtp cannot connect to Verizon Wireless Galaxy S III [NEEDINFO]
libmtp cannot connect to Verizon Wireless Galaxy S III
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: libmtp (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Linus Walleij
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-16 10:50 EDT by Jonathan Kamens
Modified: 2014-02-09 11:13 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-13 15:41:36 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
phatina: needinfo? (triad)


Attachments (Terms of Use)

  None (edit)
Description Jonathan Kamens 2012-07-16 10:50:48 EDT
$ mtpfs /tmp/android
Listing raw device(s)
Device 0 (VID=04e8 and PID=6860) is a Samsung GT-P7310/P7510/N7000/I9100/Galaxy Tab 7.7/10.1/S2/Nexus/Note.
   Found 1 device(s):
   Samsung: GT-P7310/P7510/N7000/I9100/Galaxy Tab 7.7/10.1/S2/Nexus/Note (04e8:6860) @ bus 1, dev 12
Attempting to connect device
PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP libusb: Attempt to reset device
LIBMTP PANIC: failed to open session on second attempt
Unable to open raw device 0
$ 

dmesg output:

[165142.718035] usb 1-3: new high-speed USB device number 12 using ehci_hcd
[165142.834852] usb 1-3: New USB device found, idVendor=04e8, idProduct=6860
[165142.834858] usb 1-3: New USB device strings: Mfr=2, Product=3, SerialNumber=4
[165142.834863] usb 1-3: Product: SAMSUNG_Android_SCH-I535
[165142.834867] usb 1-3: Manufacturer: SAMSUNG
[165142.834870] usb 1-3: SerialNumber: 3a03601b
[165216.336041] usb 1-3: reset high-speed USB device number 12 using ehci_hcd
[165438.321044] usb 1-3: reset high-speed USB device number 12 using ehci_hcd

I ejected the device in GNOME before attempting to use mtpfs on it, so I don't think gphoto2 is interfering.
Comment 1 Linus Walleij 2012-07-17 17:25:19 EDT
When you try this, make sure the screen is unlocked on the device.

Android do not allow you to connect to a device with locked screen so as to avoid MTP being used as a backdoor.

Pls verify that screen is unlocked when testing.
Comment 2 Jonathan Kamens 2012-07-17 22:24:53 EDT
Yes, confirmed, screen is not locked. libmtp still hangs.
Comment 3 Linus Walleij 2012-07-18 04:49:06 EDT
I am using a similar device so I'm a bit confused :-/

What I do is start the program "gnomad2" (wrote it myself that's why...) and plug in the device when the program is running. This always works. Rhytmbox also mostly works the same way: program needs to be up before connecting the device.

Can you test if this works? In that case we need to reassign the bug to mtpfs as the library works in other contexts.

Please also try the command-line programs like "mtp-detect" and "mtp-files" from the package "libmtp-examples" and see what happens. They usually need to be run shortly after the device was plugged in, since Androids seem to get "numb" if you don't use them quickly enough.
Comment 4 Jonathan Kamens 2012-07-18 06:58:50 EDT
(In reply to comment #3)
> I am using a similar device so I'm a bit confused :-/

Define "similar". Every new device that comes out has slightly different tweaks in it. And are you using the vendor-supplied image, or a CyanogenMod image or something like that?

Are you sure the device you're using is being talked to with MTP rather than USB Mass Storage? For some reason Verizon Wireless and/or Samsung decided to disable USB Mass Storage in the Verizon Wireless version of the Galaxy S III, so I'm stuck using MTP, which really doesn't work as well.

> What I do is start the program "gnomad2" (wrote it myself that's why...) and
> plug in the device when the program is running. This always works. Rhytmbox
> also mostly works the same way: program needs to be up before connecting the
> device.

Gnomad2 has the same problem for me. Here's what it reports on the console when I start it up and then plug in the S III:

$ gnomad2 
PDE device NULL.
add event for /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3 (bd0a)vendor = 4e8, model = 6860, bus = 1, device = b
device is MTP or libnjb compliant
PDE device NULL.
Unhooked, hook this device!
PDE device NULL.
Device 0 (VID=04e8 and PID=6860) is a Samsung GT-P7310/P7510/N7000/I9100/Galaxy Tab 7.7/10.1/S2/Nexus/Note.
PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP libusb: Attempt to reset device

> Please also try the command-line programs like "mtp-detect" and "mtp-files"
> from the package "libmtp-examples" and see what happens. They usually need
> to be run shortly after the device was plugged in, since Androids seem to
> get "numb" if you don't use them quickly enough.

mtp-detect has the same problem.
Comment 5 Linus Walleij 2012-07-18 07:51:20 EDT
Yes I know all about different devices (having authored libmtp)
but I had the impression that most recent Samsungs were using
similar MTP stacks and not all that deviant from each other,
that's why I'm a bit confused.

In essence what you're saying is that I have no chance to
duplicate the behaviour unless I get a device like this and
sadly my budget is $0.

I'd suggest cloning libmtp from git and start hacking, the
INSTALL file gives all details on how to proceed altering
LD_LIBRARY_PATH to use the fresh-compiled version.

git clone git://libmtp.git.sourceforge.net/gitroot/libmtp/libmtp
Comment 6 Jonathan Kamens 2012-07-18 08:40:33 EDT
No need to be snarky, I didn't know you were the libmtp author. I'm doing the best I can to give you as much information as possible.

I've managed to get it to work intermittently by disabling gvfs-gphoto2, but only intermittently (so I'm not actually sure that disabling gvfs-gphoto2 was relevant). I got mtp-detect to work once, but not a second time, even after unplugging and replugging the device and making sure it wasn't locked. I got mtpfs to work once, but it can only see directories -- no files -- on the mounted device.

When mtp-detect or mtpfs works, it takes a long time, on the order of a minute, to detect the device.

Is it possible that this is related to the amount of data I have on the device? I have thousands of music files. Is it possible that they all need to be enumerated at connect-time, and that's taking a long time, and libmtp isn't waiting long enough? Is there a timeout setting I can increase?

Is there a debug flag or something that I can pass to mtp-detect to get it to print out more verbose information about what it's doing when it's trying to connect to the device?
Comment 7 Linus Walleij 2012-07-18 08:52:51 EDT
On the possible intervening gvfs you might be onto something, I think it is possible to configure which application takes precedence when a device is plugged in. I somehow managed to get gnomad2 to hog it first, but this definately needs looking into, maybe a more precise bug can be filed agains gvfs-gphoto2?

Yes the amount of data is a factor. Have you tried the command mtp-filetree? It uses the new per-item lookup calls that are better suited to match the way Google implemented their MTP stack.

Another program that reportedly works better with MTP devices is go-mtpfs, I don't think this program is yet in Fedora, but maybe you can compile it and test.

Atleast some of the MTP example programs can be supplied with the -d flag to print verbose debug info.
Comment 8 Jonathan Kamens 2012-07-18 10:02:39 EDT
Thanks for your help. I understand what's going on much better now. I'm not really sure there's any way for Fedora or libmtp to do any better than it's doing. Let me explain what I've learned...

The README for libmtp mentions, and you mentioned as well, that some Samsung devices go "numb" if you don't connect to them within a short time after they are plugged in. The README file said 7 seconds, I believe, and I was connecting well within that range. However, it turns out that the timeout for my SIII appears to be much less, like around 2-3 seconds. If I wait any longer than that after plugging in the USB cable before connecting with libmtp, it doesn't work.

I was able to connect reliably with libmtp by (a) killing gvfs-gphoto2-volume-monitor and (b) running the libmtp command pretty much immediately after plugging in the device. One time I managed to run the command _too_ quickly, probably before USB had settled, but that wasn't the norm.

Mtp-detect, mtp-filetree, and mtpfs all read all of the file metadata from the device before returning, so even when they connect successfully, they take a very long time on a device with lots of files, and therefore it could appear that they are hanging. I'm not sure if there is a way to improve this behavior, either by eliminating the need for them to read everything up-front, or by giving some sort of progress indication of what they're doing so it doesn't look like they're hanging.

Even when I connect successfully with mtpfs, it still only sees directories, not files. I am going to file a separate mtpfs bug about this.

The go-mtpfs tool you referenced works great and is exactly what I need!

Thanks again.
Comment 9 Linus Walleij 2012-07-18 17:48:33 EDT
Hm, how do you actively kill gvfs-gphoto2-volume-monitor?

Maybe I should look into some way of hooking Gnomad2 and the Rhytmbox plugin into the volume monitor as well. Atleast there must be a proper way to disable the gphoto2 plugin.

The ideal is if the programs are run right after insertion, after udev has signalled to the app that the device is there. Probably the mtp-* examples should be enhanced with some rudimentary udev support so they display something like "waiting for device to be plugged in" if no device is detected.

I'm a bit puzzled about mtp-filetree being slow, it is explicitly uncached, so it does not read in all files on start. Then it prints out files as it traverses the file system. This is a bit odd...

PS sorry for my grumpiness earlier, this was more a sign of despair.
Comment 10 Jonathan Kamens 2012-07-18 17:56:51 EDT
(In reply to comment #9)
> Hm, how do you actively kill gvfs-gphoto2-volume-monitor?

Just do "ps aux | grep gphoto2" to find the PID and send it a kill signal.

Perhaps there's a better way to do it, but that works. :-)
Comment 11 Linus Walleij 2012-07-18 18:17:49 EDT
Does:

pkill gvfs-gphoto2-volume-monitor && mtp-detect

work nicely?
Comment 12 Jonathan Kamens 2012-07-18 18:19:51 EDT
You can't do it all at once like that, because you need to kill volume-monitor, then plug in the phone, then run the mtp-detect command within a couple seconds of plugging in the phone, or the phone goes numb. The timing is key. So you need to do it as two separate commands, separated by the physical act of plugging in the phone.

You need to kill volume-monitor before you plug in the phone because otherwise it might try to connect to it and mess things up.
Comment 13 John Griffiths 2012-11-02 14:57:30 EDT
http://forums.fedoraforum.org/showthread.php?t=284741

jmtpfs works like a charm on my Samsung Galaxy S III.
Comment 14 Linus Walleij 2012-11-13 15:41:36 EST
I conclude, since jmtpfs is working that this is atleast not a libmtp bug & closing...
Comment 15 Peter Hatina 2014-02-09 11:13:26 EST
I can see similar behaviour with libmtp.

At first try, I can do LIBMTP_Open_Raw_Device_Uncached() and work with a Nexus 5.
Second try, I am not successful. libmtp waits for 1 minute and then issues libusb_reset(), which makes Nexus 5 work with the library.

In sources, you state, the reset is for bad applications, which do not call LIBMTP_Release_Device. I call this every time, I am done communicating with the phone.

The same situation is with Nexus 7 or Galaxy Nexus.

Can you provide any valuable help with this?

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