Uh, okay, my bad. Then i is possibly uninitialized though (when devh is unset).

Update for 2.5.2

Sorry for the bump.
Seems like this one has been silently applied and thus the issue is resolved.

Most likely a typo here.

The char pointer should be dereferences when checking the string is empty.

Looked a bit further into the issue. The phone misbehaves (ignores one message) in most cases when the endpoint is reset prior to issuing the allow remove (0x1e) command. It doesn't seem to happen when the one of the few commands preceding the reset is test unit ready (0x00) which explains why it wo...

Hi,

It seems that the patch from the following post got applied incompletely
http://www.draisberghof.de/usb_modeswit ... f=2&t=1635

Here's what's left:
http://pkgs.fedoraproject.org/cgit/rpms ... ages.patch

Thank you,
Lubo

No, the testing was not automatic really; I was hunting down another bug (see http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=2&t=2557) and happened to call the tool with a wrong parameter. The crash was then caught by ABRT which makes it convenient to track the crashes and also sav...

Whoops, the patch was wrong, since it's the usb_modeswitch-data that passes the %b argument. Updated the patch to keep the compatibility. This is not too nice though. Ideally, the data package should tag the device for the modeswitch with TAG+="usb_modeswitch" rule and then the usb_modeswi...

In the better case it's empty and useless, in worst case it's something very irrelevant (a bus name of a random parent of a device that happens to have one, such as the usb controller) and harmful -- when passed to the dispatcher it appends it to the sysfs path, making it invalid. To add insult to i...

Hmm, blacklisting sr_mod and cdrom modules fixes the issue.
Need to look into what do they do.

I think we may get that reply if we only wait long enough for it, can you try to add a delay instead of doing a retry? 100mS could be a reasonable value. The current timeout is 3 seconds. I've previously tried to raise it to 30 seconds, but that didn't change anything. I don't think we are talking ...

LOM wrote:I think we may get that reply if we only wait long enough for it, can you try to add a delay instead of doing a retry? 100mS could be a reasonable value.

The current timeout is 3 seconds. I've previously tried to raise it to 30 seconds, but that didn't change anything.

What kind of hardware is the host, a very fast computer? Hopefully not a Raspberry Pi.. According to the DMI it's a ThinkCentre M73 with BIOS dated 12/2015. Doesn't seem like an old machine. Has a 4th i3-4150 CPU and the phone is plugged into an USB 2.0 port of "Intel Corporation 8 Series/C220...

There were no other reports about such a problem on other distros, AFAIK. Is there an official Fedora bug report? Not really. I've stumbled upon this myself when checking things work well with my modem collection after updating the package. The users don't tend to include too much details in the bu...