Bug 733183

or can you del all the ZTE VID's file in /etc/usb_modeswitch,like 19d2:xxxx because we need not this tool in fact. 
Thank you very much!

It is not clear what you intend to do. Can you try to explain more precisely?

If you say "we need not this tool in fact", who are you referring to?

Any user of Fedora needs to switch ZTE devices to modem mode in order to make it usable. If usb_modeswitch does not do it, who or what will do the job?

The non-selective behaviour of the driver binding is a problem of the module mechanism which should be fixed in the kernel.

Dear Josua,
    Thanks for your reply.
Let me explain why it is a problem for us and user.

Because each our product (3G-dongle)will have a disk-mode which have driver and User Interface（UI）software,the users who buy the 3G-dongle can install this software on their linux system.

But as the usb_modeswitch tool will eject the disk-mode to modem mode,
so our engineer have added a extra disk in mass-storage driver on modem mode which have the same PID and VID to avoid user can not install our software.

So the disk and modem now have the same PID and VID in modem-mode, and the different between them are the class sub-class and protocol which defined on USB protocol.

But the new usb_modeswitch tool have another function which i said before，It will mate the ZTE pid which contain in it tabulation and install the serial driver(option.ko) only mating PID and VID. 

The disk which shoule be installed on mass-storage driver was installed the serial driver(option.ko).If so, the disk will not appear and the user can not find our software,so they will be complain about our company.

Now can you understand?

We can accept the usb_modeswitch tool to change our 3G-dongle from disk-mode to modem-mode automatically.
 
So please modify the files 19d2:2000,19d2:0026 in /etc/usb_modeswitch/
, change the name "TargetProductList" to "TargetClass" and the value is 0xff,
or can you del all the ZTE VID's file in /etc/usb_modeswitch?

It may be difficult for you but I can not contact with this tool's author, and our customers only complain to us about they can not install our software on the fedora 15, so i can only ask you for help.

Thanks!

By the way, I am this tool's author. Nobody did try to contact me.

Well, what would happen if I'd do what you suggest?

1. Changing all ZTE devices in "19d2:2000" to ignore the target ID:

Most of the devices are bound automatically because their ID is already in the "option" driver. usb_modeswitch will ONLY bind new models that are not known to the driver, which are very few. So you get the driver bound to the vast majority of ZTE devices in the same way no matter who is doing the mode switch.

To prevent the driver from binding you have to blacklist "option" or modify the source code "option.c".

2. Removing all ZTE devices from usb_modeswitch would mean there is no mode switch by the system.
O.K., I tested this with my MF110 by disabling mode switching globally. Indeed the pseudo CD-ROM can be accessed, but there is only Windows software on it. Then I switched the mode with the help of "eject"; this is what I got:

sr 13:0:0:0: [sr1]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 13:0:0:0: [sr1]  Sense Key : Illegal Request [current]
Info fld=0x0
sr 13:0:0:0: [sr1]  Add. Sense: Logical block address out of range
sr 13:0:0:0: [sr1] CDB: Read(10): 28 00 00 00 64 c6 00 00 02 00
end_request: I/O error, dev sr1, sector 103192

The pseudo CD-ROM is not accessible after that. If it were, would I find Linux software on it? Would it work on every distribution out there?

Dear Josua,
    Sorry for i had not recognized you.I only sent this mail to
Didier Raboud few month ago and have not received any reply.

    Of course, removing all ZTE devices from usb_modeswitch is a last method.

    By the way,if you Changing all ZTE devices in "19d2:2000" or "19d2:0026" 
to ignore the target ID, then the device can be only changed from disk-mode to modem-mode and then the option driver can recognize and install.

Then the senior user like you can use each port for yourselves and 
the primary user can install UI(if have, and for this guys, 
they will see if the device can support Linux before they buy it,
and in other words，if they find the device does not support linux on 
user manual do you agree?)

I think the best way is make your software's to match the device by use pid,vid,class,subclass protocol before install option driver.

For ZTE device,the target pid such as "19d2:0031",
the serial port is 0x19d2:0x0031:0xff:0xff:0xff,and 
the mass-storage port is 0x19d2:0x0031:0x08:0x06:0x50

What do you think？

thanks!

I will try to analyze the situation more precisely:

We are watching two cases:

1. The ID of the modem is already added to the "option" driver

 * usb_modeswitch will switch to modem mode
 * it will wait a moment, then check if the driver has bound automatically
 * it finds new serial interfaces and DOES NOTHING

2. The ID of the modem is unknown yet (new model, new variant etc.)

 * usb_modeswitch will switch to modem mode
 * it will wait a moment, then check if the driver has bound automatically
 * it does not find new serial interfaces
 * it loads the "option" driver
 * it uses the dynamic driver binding via "new_id"

Thanks to the "wait a moment", any storage driver will already have bound to freshly discovered class 8 interfaces. The serial driver will ONLY bind to hitherto unbound interfaces.

Do you have any reports that the "option" driver was mistakenly bound to mass storage interfaces? If so, I can adjust the "moment of wait" which is currently 500 ms. 

Just like in my previous posting, there are lots of error reports regarding the storage access after switching, but these are pointing to "mode sense" problems, after binding of the storage driver.

Do you believe they are caused by the "option" driver? If so, how?

Created attachment 529162 [details]
usb_modeswitch_ttyUSB1 which interface one is mass-storage picture

Dear Josua,
    Thanks for your help!You are so intelligent!
I think your method are useful.Please sent the test rpm package to me after you have modify finish.
    
I have not save all the report,but i will describe it which the attachment show.
For example,when i use the device MF190 (default 19d2:2000 ;target 19d2:0031)with four interface and the interface one is mass-storage port the others are serial port , test on fedora 15.

When i plug the device for a moment,i can find from "dmesg" that the option driver will be installed on all the interface. 
At the same time, i had opened the usb_modeswitch debug macro in /etc/usb_modeswitch.conf and would find the usb_modeswitch_ttyUSB0,usb_modeswitch_ttyUSB1,usb_modeswitch_ttyUSB2 and usb_modeswitch_ttyUSB3 from /var/log，and the file usb_modeswitch_ttyUSB1 used the interface one as it talked.

I find it can be restored as the following steps：
1.modprobe -r option
2.modprobe -r usb-storage
3.modprobe  usb-storage
4.modprobe  option
After this, it will be normal whatever you plug or unplug to the computer unless restart the computer.

I do not think it was caused by the option driver directly because it will not happen if i do not use the usb_modeswitch tool or change our device pid which is not contained in your list. 
By the way, the option driver have used the strong match rules(vid,pid,interface_class,interfacesub_class,interface_protocol)

Thanks!

Created attachment 529163 [details]
usb_modeswitch_all picture

the device have four interface and the interface one is mass-storage port but have installed four serial driver (option)

Note: the log files for the ttyUSB ports that you find are NOT related to driver binding!
They are the result of a convenience function in usb_modeswitch which creates a symbolic link to the ttyUSB port with "interrupt transfer mode". This is usually the port to use for connection. You may find a symbolic link "/dev/gsmmodem" pointing to that port after the mode switch.

I can't do RPMs, I provide only a source package. But since the most components of usb_modeswitch are script or text files, you can easily change and adapt them yourself.

Here is what I recommend to do:

1. Edit /lib/udev/usb_modeswitch

2. After line 37, insert a line reading "sleep 1". The line after that
   should be (just for comparison, don't change):
   "if [ ! -z "$dir" ]; then"

See if that improves the situation.

For double checking, the edited file should look like this:

    ...   
    dir=$(ls -d /sys$2/ttyUSB* 2>/dev/null)
    sleep 1
    if [ ! -z "$dir" ]; then
        exit 0
    fi
    ...

ok i will try，thanks！

Created attachment 529584 [details]
script of the usb_modeswitch from fedora 15

Dear Josua，
    i could not find this on my fedora 15 formal edition.

    dir=$(ls -d /sys$2/ttyUSB* 2>/dev/null)
    if [ ! -z "$dir" ]; then
        exit 0
    fi

I have upload it from my computer as attachment：“usb_modeswitch”，
please have a look！
thanks！

I just discovered that the Fedora package maintainer decided to throw out the small shell script. Plus, he patched in changes from a later version to the Tcl script.

I'm not sure why he did that as it breaks some things. For instance, a new model that was driver-bound by usb_modeswitch (because the kernel driver does not know the ID yet) will NOT get the driver again after warm booting ...

Anyway, for you it means there is annother place to look for.

See line 355 to 356 in your script. It says:

# some settling time in ms
after 500

Now increase that "500" value to 1000 (or more as you like). This should be plenty of time for the storage driver to bind before usb_modeswitch starts binding the "option" driver.

By the way, I just proposed a kernel patch which would make it possible to limit the dynamic driver binding to one specific interface class. There was no way to do that before:

http://www.spinics.net/lists/linux-usb/msg53356.html

Dear Josua，
     Thanks a lot for your help！
     I have tried to modify the delay as what you said，and add it to 1000，5000
，but unfortunately，it useless.I also tried to add it before chaeck the driver and also unwork.
    I suggest you test meanwhile， do you have zte modem？ You can add your device pid to TargetProductList in the file /etc/usb_modeswitch.d/19d2:2000/ and restart the computer.
After login, then plug on the device and see if it can happen.
May be some times.

Thanks!

As I have written in comment #4, I own a ZTE MF110.

I tried to provoke the error that you are seeing. For me, it is only possible if I disable "usb-storage" completely, by moving it away from the modules tree.

There is no way to prevent the binding of the storage driver for such a long time. I suspect the problem is elsewhere. But maybe you can attach the log of usb_modeswitch with the long delay active?

You can also add the "NoDriverLoading=1" parameter to the config file of the device, and usb_modeswitch will not do any binding after mode switching.

Created attachment 530430 [details]
before add the NoLoadingDriver parameter 's log

Created attachment 530431 [details]
after add the NoLoadingDriver=1 parameter 's log

Dear Josua，
    After add the NoLoadingDriver=1 parameter， is will be ok if it can effect.
(I add it in /lib/udev/usb_modeswitch.）But some times it seems not effect see from log(will see "ok:19d2:0117", the correct is "ok:"), and then the error happened at the same time.

The logs are normal and as expected.

Now we need to look at the kernel output, including time stamps.

So, can you try again to plug the modem

- WITHOUT the NoDriverLoading parameter

- WITH the delay (2000 should really be more than enough)


Remember to unload the "option" driver after each unplugging with
"modprobe -r -v option"!
This is important, otherwise it will remember the ID and will bind immediately at the next plug-in time, with no delay at all.

Then run "dmesg" or see the end of /var/log/syslog. You will see in what order the device discovery and the driver binding is happening.

Created attachment 530607 [details]
add_delay_to_2000_driver_install_error

Created attachment 530608 [details]
add_delay_to_2000_driver_install_nomal

Created attachment 530609 [details]
without NoLoadingDriver

Dear Josua，
    I set delay to 2000 and found it would some time nomal,but another time error. 
See from the attachment.
thanks!

Now this is obvious in your "error" log:

[  418.206009] usb 1-1: new high speed USB device using ehci_hcd and address 7
...
[  421.915204] Initializing USB Mass Storage driver... 

That is 3.5 seconds delay for "usb-storage" to become active !!!

I'm beginning to suspect that the change the Fedora maintainers applied to the upstream package is causing this error. The little shell script they kicked out ensures that the run of usb_modeswitch will fork to the background and NOT hold up the udev process. This is what may be happening here so that "usb-storage" is waiting for usb_modeswitch to finish, which is very non-clever ...

I suggest that you test the upstream package, either the old 1.1.7 version or the current 1.2.0 (or both):

http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-1.1.7.tar.bz2
http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-1.2.0.tar.bz2

Just do "make install" in the unpacked source folder.

If the finding described in comment #24 is the reason for the reported problem, then it would explain why other packaged versions of usb_modeswitch (Debian, Ubuntu) never showed this error.

I'm looking forward to those test results!

Created attachment 530623 [details]
install wrong

"make install" and found error.
please have a look

I forgot to mention that you need to install "libusb-devel" first.

Created attachment 530901 [details]
change to 1.17 driver

Dear Josua,
    I have installed the driver which you given me successful. 
And both of the 1.1.7 and 1.2.0 driver have same log like the attachment.

And good news，the error have not happened any times during in my test.
(When i installed the 1.2.0 driver firstly ,and after plug the device, the kernel down,but it can not happen later)

   May be it really happned on fedora only like you suspect.

Fedora maintainers:

I strongly suggest to use the scripts the way they are in the upstream package:
let the wrapper script be launched by the small sh script instead of running it directly from udev.

Obviously there is no background processing in the Fedora package. This may hold up the device discovery process for the time that the respective device needs to switch modes. That time ranges between 1 and 20 seconds.

Furthermore, as this report is indicating, storage driver binding seems to be affected. That may lead to the problems described here, affecting the post-switch device discovery process.
Also, there are devices that will only accept the switching command (in most cases an UFI command) if they had received some initialization by the usb-storage driver; the pre-switch driver binding is essential in these cases. As the kernel logs suggest (see attachments above), the storage driver is not active before the moment of mode switching ("USB disconnect").

The upstream configuration is used in the official Debian package with very little adaptation, achieving good results with respect to reliability.

After further thoughts, I suspect that bug #697122 was caused by the same issue. The run of usb_modeswitch may have blocked the binding of the "cdc_acm" driver.

That would explain why the problem with the wrongly bound "option" driver did not occur on systems using the Debian package.

Dear Josua，
    Does it need to add someone else to discuss this error？
If so， please tell me those people's mail, because it has not replied by anyone else so far.
Thanks！

Lirui, I could only tell you what is written on top of the bug report page ...

I have a ZTE MF626 and it only works sometimes when I plug it on my computer. If it is not reconized (something that happens 4 times of every 5 attemps aprox.) I have to shutdown the computer and restart it.

Now I have tried to execute the command "eject" and the dongle is recognized as modem and it works fine. I wil try to reboot and check if the "eject" trick always work.

Re #33: I suggest trying the upstream packages linked above. I suspect the unreliability that you see may be caused by the issue described in comment #29.

Thanks Josua, I will give it a try.

I have alerted on Fedora Forums if any of the developers that visit that forum can contact the package mantainer about this report.

Created attachment 533765 [details]
usb_modeswitch log for ZTE MF626

I have installed usb_modeswitch from upstream.

Created attachment 533766 [details]
dmesg log for ZTE MF626 dongle using upstream usb_modeswitch

Hi Josua, I have installed the upstream package but the unreliability issue persists. I have attached my usb_modeswitch log and dmesg message.

Thanks!

Hmm, both logs look just fine. Mode switching has worked and serial ports are up.

You may have to specify what you mean when you say "not recognized".
Are you by any chance talking about Network Manager?

Yep, I don't have been promted to enter the pin and the broadban connections is not shown on NetworkManager.

This is not a problem with usb_modeswitch.

It may happen that modems are not properly discovered by "modem-manager". You will be able to connect with other programs that allow inserting the port name manually. This is not possible with Network Manager, AFAIK.

Yes, it looks like a modem-manager problem. If I execute modem-manager --debug, it ends with this message:

modem-manager[3619]: <debug> [1321373246.272714] [mm-modem-base.c:155] mm_modem_base_add_port(): (ttyUSB0) type QCDM claimed by /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-6
modem-manager[3619]: <info>  [1321373246.272825] [mm-manager.c:564] do_grab_port(): (ZTE): GSM modem /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-6 claimed port ttyUSB0
modem-manager[3619]: <debug> [1321373246.272968] [mm-manager.c:243] check_export_modem(): (tty/ttyUSB2): outstanding support task prevents export of /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-6
modem-manager[3619]: <debug> [1321373249.263528] [mm-serial-port.c:838] mm_serial_port_close(): (ttyUSB2) device open count is 0 (close)
modem-manager[3619]: <info>  [1321373249.263668] [mm-serial-port.c:853] mm_serial_port_close(): (ttyUSB2) closing serial port...
modem-manager[3619]: <info>  [1321373249.264857] [mm-serial-port.c:874] mm_serial_port_close(): (ttyUSB2) serial port closed
modem-manager[3619]: <debug> [1321373249.265016] [mm-manager.c:624] supports_callback(): (tty/ttyUSB2): ignoring port unsupported by physical modem's plugin

Maybe I should report a new bug?

Hi Juan，
    After usb_modeswitch worked，please use “lsusb -v -d 19d2:0066” and 
upload the log.
    And i also support you can stop the usb_modeswitch, and use "eject" 
to see if it will be fine.

Created attachment 533917 [details]
Output from command lsusb -v -d 19d2:0066 after usb_switchmode.

On the terminal when execute the command lsusb -v -d 19d2:0066 I get the message: Couldn't open device, some information will be missing

Created attachment 533918 [details]
Output from command lsusb -v -d 19d2:0066 as superuser after usb_switchmode.

Hi lirui, I have attached the output of the lsusb command (please, ignore the first one because I don't execute it as superuser and was getting a warning). The eject command doesn't work either after disabled usb_modeswitch, it switches to modem mode but modem-manager doesn't recognizes it.

Hi Juan，
    I think the command “eject” had completed it's work successful，
can you try to use minicom tool to test the AT command on port ttyUSB3.
If it can work, then try to use wvdial tool to diag and connect the network.
Then we can see if it is the problem about modem-manager problem.

Hi lirui,

I never used minicom tool before, but if I execute minicom --device /dev/ttyUSB1 I get this message:

AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0                   
ERROR

On wvdial I get this other one:
--> WvDial: Internet dialer version 1.61
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: ATQ0 V1 E1 +FCLASS=0
ATQ0 V1 E1 +FCLASS=0
OK
--> Modem initialized.
--> Sending: ATDT*99#
--> Waiting for carrier.
ATDT*99#
ERROR
--> Invalid dial command.
--> Disconnecting at Wed Nov 16 11:55:11 2011


wvdialconf generate this file on /etc/wvdial.con (I have replaced the commented lines with my ISP params):

[Dialer Defaults]
Init2 = ATQ0 V1 E1 +FCLASS=0
Modem Type = Analog Modem
Phone = *99#
ISDN = 0
Username = movistar
Init1 = ATZ
Password = movistar
Modem = /dev/ttyUSB1
Baud = 9600

I don't know how to set the APN and the pin on wvdial

Hi Juan，
    Can you use windows to set apn firstly?Or you have to install minicom  tool and set by it.
Then modify those file for wvdial:
1.modify file /etc/wvdial.conf 
[Dialer Defaults]
Phone = *99#
Username = TIM
Password = TIM
Stupid Mode = 1
Dial Command = ATDT
Modem = /dev/ttyUSB3
Baud = 115200
Init2 = ATZ
Init3 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ISDN = 0
Auto Reconnect = off
Modem Type = Analog Modem
2.modify file /etc/ppp/options
/dev/ttyUSB3
115200
debug
noauth
noipdefault
#persist
defaultroute
usepeerdns
crtscts
lock
asyncmap 20A0000 
kdebug 4
netmask 255.255.255.0
-detach
lcp-echo-failure 4
lcp-echo-interval 30
ipcp-max-failure 30
ipcp-max-configure 30
-ccp
-vj
#user	li
#hide-password
3.modify file /etc/ppp/peers
noipdefault
ipcp-accept-local
ipcp-accept-remote
defaultroute
debug
noauth
name wvdial
usepeerdns
#lcp-echo-failure 0
#lcp-echo-interval 0
#usepeerdns

Hi lirui,

I know that my APN is movistar.es, but I don't know how to set it at wvdial.conf. I have found this wvdial.conf line on internet, is ok?

Init3 = AT+CGDCONT=1, "IP","movistar.es"

Thanks lirui for your effort.

(In reply to comment #29)
> Fedora maintainers:
> I strongly suggest to use the scripts the way they are in the upstream package:
> let the wrapper script be launched by the small sh script instead of running it
> directly from udev.
> Obviously there is no background processing in the Fedora package. This may
> hold up the device discovery process for the time that the respective device
> needs to switch modes. That time ranges between 1 and 20 seconds.
> Furthermore, as this report is indicating, storage driver binding seems to be
> affected. That may lead to the problems described here, affecting the
> post-switch device discovery process.
> Also, there are devices that will only accept the switching command (in most
> cases an UFI command) if they had received some initialization by the
> usb-storage driver; the pre-switch driver binding is essential in these cases.
> As the kernel logs suggest (see attachments above), the storage driver is not
> active before the moment of mode switching ("USB disconnect").
> The upstream configuration is used in the official Debian package with very
> little adaptation, achieving good results with respect to reliability.

Does any one of fedora maintainers can help？

Dear Josua,
    I advise you that do not update and add ZTE product ID on your software before this bug fix.
Thank you！

Dear Josua,
    How are you！ I find a new condition. I try to use the same dongle （default pid 0x2000，target pid 0x0031）on fc15 （2.6.38.6-26.rc1.fc15.i686），only the hardware is different（DELL PC and FUJITSU PC）. On FUJITSU‘s computer， the result is fine，see log 2638_2000_0031_fujitsu_ok；
but on DELL’s computer，the bug is happened，see log 26382000_0031_dell_error.

Created attachment 548536 [details]
fujitsu's computer

Created attachment 548537 [details]
dell's computer

Lirui, what about the usb_modeswitch version on the Dell? Unchanged Fedora package or modified/upstream?

Dear Josua,

    Unchanged Fedora package!

And our test engineers found aother bug（may be i think is the same condition which i found yesterday）：
    They try about four computer on other dongle MF190(default pid 0x2000;target pid 0x0039 which not include in usb_modeswitch.d)yesterday，
other computer were fine because this target pid 0x0039 not mated in usb_modeswitch.d as we know.
But only DELL's have problem，（log almost like 26382000_0031_dell_error）and this problem can only reproduce after “ Bug 704846 ” happened,as:
1.plug on a dongle which can mount a disk
2.unplug the dongle make the kernel crash
3.restart the computer
4.plug the MF190(default pid 0x2000;target pid 0x0039)
5.mass-storage interface wrong mate and install the serial driver option.

Now i confused about this:
    In nomal condition, the four conputer are fine because this target pid 0x0039 not mated in usb_modeswitch.d.
    But in special condition(Bug 704846 happen)，it only happened on Dell compter about 100 percent ，and other’s computer not happen so far.  

So which is your opinion?
    Looking forward by your reply!

Created attachment 548772 [details]
usb_modeswitch_for_dell_after_crash

Created attachment 548773 [details]
usb_modeswitch_for_fujitsu_after_crash

Created attachment 548777 [details]
this_log_show_after_kernel_crash_fujitsu_ok

Created attachment 548796 [details]
dmesg_fc15_2.6.38_after_kernel_crash_dell

Dear Josua,

    How are you？any update？

As stated before, I have done what I can in the upstream package. The version is 1.2.1 now.

I have incorporated the coming change in the kernel where the "new_id" attribute will accept an interface class and bind the driver only to interfaces with that class. This will prevent the "wrong effect" issue from ever happening again.

It will take a while though until kernel 3.3 with my accepted patch will arrive in Fedora.

It's up to the Fedora package maintainer now to correct the error that I have pointed out.

Dear Josua,
    Thanks for all your help！
As what your said，i suggust that please do not update any new ZTE and D-link pid（target and default）on usb-modeswitch-data any more before Fedora package maintainer fix the bug，thanks！

Fedora package maintainers:
    Please pay attention to this bug and correct the error as soon as possible！
Thank you！

..please stop adding me to the CC list. I don't know anything about usb_modeswitch and I don't test or maintain anything relevant to this bug.

I do, however, have a little advice. If you want to get this fixed you need to explain the problem *clearly* and propose a *concrete* solution - ideally a patch that you've tested yourself.

Remember that developers are busy people, and that every comment on this bug will send every developer on the CC list an email. So we've all gotten ~40 emails making demands like "correct the error as soon as possible!" without saying what the error actually *is*, or *how* to correct it. (ex. comment #24 mentions "a little shell script", but doesn't say *what shell script*.)

Explain clearly what's wrong and what needs to be changed (and why) and you'll have a much better chance of getting this fixed soon.

O.K., once again, hopefully simple enough.

The Fedora package has problems that the upstream and the Debian package don't have, due to the changes that the Fedora maintainers chose to introduce.

No patch is necessary; it's all in the upstream source package.

Don't put the dispatcher script into /lib/udev directly. Put it into /usr/sbin and let it be called by the bash/dash script that ensures that the respective udev thread is not blocked. In short: "make install".

Or correct the errors that are introduced by the changes if they are indeed made for a good reason.

I have no idea who or what added people to the CC list (I certainly didn't). But I sure would like to have a maintainer look into this. So far, there is no sign about that happening.

usb_modeswitch-1.2.2-2 should fix this issue, can someone test and let me know if it works?

Dear Huzaifa，
    As i had tested before，if you get usb_modeswitch tool（version >= 1.1.7） from
http://www.draisberghof.de/usb_modeswitch/
and directly install to the fedora OS,it will fix this bug.So usb_modeswitch-1.2.2-2 can fix this issue.

Removing CommonBugs tag, Fedora 16 is long time released.

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.