Description of problem:
the usb_modwswitch tool will change the ZTE dongle to mutil-device mode(modem mode）, and will install the serial driver only based on the weak matching rules(only base on VID 0x19d2 ，PID 0x2000 or 0x0026), so it will wrong to install the mass-storage device（port）but a serial driver, so it will cause the USER can not found the cd-rom to install the device UI.
Version-Release number of selected component (if applicable):
fedora15 188.8.131.52-0 and below
x86 64 bit and i686
Steps to Reproduce:
1.plug in the ZTE dongle with 19d2:2000 and the modem mode is vid：19d2 and pid：0x0001，0x0002,0x0015,0x0016，0x0017，0x0031，0x0037，0x0052,0x0055,0x0063,0x0064,0x0066,0x0091,0x0108,0x0117，0x0128，0x2002
2.the device is change to modem mode automatically by the usb_modeswitch tool
3.it will find a extra serial driver which should be installed a mass-storage driver
it will find a extra serial driver which should be installed a mass-storage driver
after it change to modem mode， the mass-storage driver can be install and the user can install the UI by open the disk
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,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.
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.
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]
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?
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？
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
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
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)
Created attachment 529163 [details]
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)
if [ ! -z "$dir" ]; then
ok i will try，thanks！
Created attachment 529584 [details]
script of the usb_modeswitch from fedora 15
i could not find this on my fedora 15 formal edition.
dir=$(ls -d /sys$2/ttyUSB* 2>/dev/null)
if [ ! -z "$dir" ]; then
I have upload it from my computer as attachment：“usb_modeswitch”，
please have a look！
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
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:
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.
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
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]
Created attachment 530608 [details]
Created attachment 530609 [details]
I set delay to 2000 and found it would some time nomal,but another time error.
See from the attachment.
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):
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]
"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
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.
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.
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.
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.
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: <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: <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: <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: <debug> [1321373249.263528] [mm-serial-port.c:838] mm_serial_port_close(): (ttyUSB2) device open count is 0 (close)
modem-manager: <info> [1321373249.263668] [mm-serial-port.c:853] mm_serial_port_close(): (ttyUSB2) closing serial port...
modem-manager: <info> [1321373249.264857] [mm-serial-port.c:874] mm_serial_port_close(): (ttyUSB2) serial port closed
modem-manager: <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?
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.
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.
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
On wvdial I get this other one:
--> WvDial: Internet dialer version 1.61
--> Initializing modem.
--> Sending: ATZ
--> Sending: ATQ0 V1 E1 +FCLASS=0
ATQ0 V1 E1 +FCLASS=0
--> Modem initialized.
--> Sending: ATDT*99#
--> Waiting for carrier.
--> 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):
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
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
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
3.modify file /etc/ppp/peers
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？
I advise you that do not update and add ZTE product ID on your software before this bug fix.
How are you！ I find a new condition. I try to use the same dongle （default pid 0x2000，target pid 0x0031）on fc15 （184.108.40.206-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]
Created attachment 548537 [details]
Lirui, what about the usb_modeswitch version on the Dell? Unchanged Fedora package or modified/upstream?
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]
Created attachment 548773 [details]
Created attachment 548777 [details]
Created attachment 548796 [details]
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.
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！
..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?
As i had tested before，if you get usb_modeswitch tool（version >= 1.1.7） from
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:
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.