Bug 733183 - usb_modeswitch wrong effect on ZTE dongle
Summary: usb_modeswitch wrong effect on ZTE dongle
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: usb_modeswitch
Version: 16
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: mail@romal.de
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-25 03:30 UTC by lirui
Modified: 2013-02-13 16:30 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-13 16:30:50 UTC


Attachments (Terms of Use)
usb_modeswitch_ttyUSB1 which interface one is mass-storage picture (1.54 MB, image/bmp)
2011-10-20 02:34 UTC, lirui
no flags Details
usb_modeswitch_all picture (1.54 MB, image/bmp)
2011-10-20 02:37 UTC, lirui
no flags Details
script of the usb_modeswitch from fedora 15 (23.34 KB, text/plain)
2011-10-22 05:26 UTC, lirui
no flags Details
before add the NoLoadingDriver parameter 's log (5.25 KB, application/octet-stream)
2011-10-27 06:40 UTC, lirui
no flags Details
after add the NoLoadingDriver=1 parameter 's log (4.68 KB, application/octet-stream)
2011-10-27 06:41 UTC, lirui
no flags Details
add_delay_to_2000_driver_install_error (2.06 KB, application/octet-stream)
2011-10-28 03:18 UTC, lirui
no flags Details
add_delay_to_2000_driver_install_nomal (2.43 KB, application/octet-stream)
2011-10-28 03:19 UTC, lirui
no flags Details
without NoLoadingDriver (2.07 KB, application/octet-stream)
2011-10-28 03:19 UTC, lirui
no flags Details
install wrong (949.27 KB, patch)
2011-10-28 08:08 UTC, lirui
no flags Details | Diff
change to 1.17 driver (2.22 KB, text/plain)
2011-10-31 06:45 UTC, lirui
no flags Details
usb_modeswitch log for ZTE MF626 (9.91 KB, application/octet-stream)
2011-11-15 13:01 UTC, Juan Francisco Fernández
no flags Details
dmesg log for ZTE MF626 dongle using upstream usb_modeswitch (2.53 KB, text/plain)
2011-11-15 13:10 UTC, Juan Francisco Fernández
no flags Details
Output from command lsusb -v -d 19d2:0066 after usb_switchmode. (6.70 KB, text/x-log)
2011-11-16 07:18 UTC, Juan Francisco Fernández
no flags Details
Output from command lsusb -v -d 19d2:0066 as superuser after usb_switchmode. (7.08 KB, text/x-log)
2011-11-16 07:20 UTC, Juan Francisco Fernández
no flags Details
fujitsu's computer (2.26 KB, text/plain)
2011-12-19 10:39 UTC, lirui
no flags Details
dell's computer (2.07 KB, text/plain)
2011-12-19 10:39 UTC, lirui
no flags Details
usb_modeswitch_for_dell_after_crash (5.46 KB, text/plain)
2011-12-20 07:45 UTC, lirui
no flags Details
usb_modeswitch_for_fujitsu_after_crash (12.10 KB, text/plain)
2011-12-20 07:46 UTC, lirui
no flags Details
this_log_show_after_kernel_crash_fujitsu_ok (2.80 KB, text/plain)
2011-12-20 07:56 UTC, lirui
no flags Details
dmesg_fc15_2.6.38_after_kernel_crash_dell (2.07 KB, text/plain)
2011-12-20 09:00 UTC, lirui
no flags Details

Description lirui 2011-08-25 03:30:15 UTC
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 2.6.40.3-0 and below 
x86 64 bit and i686 

How reproducible:


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
  
Actual results:

it will find a extra serial driver which should be installed a mass-storage driver

Expected results:

after it change to modem mode, the mass-storage driver can be install and the user can install the UI by open the disk

Additional info:

please modify the files 19d2:2000,19d2:0026 in /etc/usb_modeswitch/
, change the name "TargetProductList" to "TargetClass" and the value is 0xff

Comment 1 lirui 2011-08-25 09:23:45 UTC
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!

Comment 2 Josua Dietze 2011-10-14 13:46:35 UTC
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.

Comment 3 lirui 2011-10-15 02:20:40 UTC
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!

Comment 4 Josua Dietze 2011-10-15 17:53:23 UTC
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?

Comment 5 lirui 2011-10-17 04:45:22 UTC
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!

Comment 6 Josua Dietze 2011-10-19 19:15:57 UTC
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?

Comment 7 lirui 2011-10-20 02:34:12 UTC
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!

Comment 8 lirui 2011-10-20 02:37:35 UTC
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)

Comment 9 Josua Dietze 2011-10-20 10:12:58 UTC
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.

Comment 10 Josua Dietze 2011-10-20 10:22:43 UTC
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
    ...

Comment 11 lirui 2011-10-20 10:46:34 UTC
ok i will try,thanks!

Comment 12 lirui 2011-10-22 05:26:42 UTC
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!

Comment 13 Josua Dietze 2011-10-22 07:47:51 UTC
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

Comment 14 lirui 2011-10-26 04:43:28 UTC
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!

Comment 15 Josua Dietze 2011-10-26 13:29:30 UTC
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.

Comment 16 lirui 2011-10-27 06:40:44 UTC
Created attachment 530430 [details]
before add the NoLoadingDriver parameter 's log

Comment 17 lirui 2011-10-27 06:41:27 UTC
Created attachment 530431 [details]
after add the NoLoadingDriver=1 parameter 's log

Comment 18 lirui 2011-10-27 06:52:01 UTC
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.

Comment 19 Josua Dietze 2011-10-27 15:51:38 UTC
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.

Comment 20 lirui 2011-10-28 03:18:25 UTC
Created attachment 530607 [details]
add_delay_to_2000_driver_install_error

Comment 21 lirui 2011-10-28 03:19:04 UTC
Created attachment 530608 [details]
add_delay_to_2000_driver_install_nomal

Comment 22 lirui 2011-10-28 03:19:29 UTC
Created attachment 530609 [details]
without NoLoadingDriver

Comment 23 lirui 2011-10-28 03:22:29 UTC
Dear Josua,
    I set delay to 2000 and found it would some time nomal,but another time error. 
See from the attachment.
thanks!

Comment 24 Josua Dietze 2011-10-28 06:38:17 UTC
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.

Comment 25 Josua Dietze 2011-10-28 06:49:54 UTC
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!

Comment 26 lirui 2011-10-28 08:08:20 UTC
Created attachment 530623 [details]
install wrong

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

Comment 27 Josua Dietze 2011-10-28 09:43:23 UTC
I forgot to mention that you need to install "libusb-devel" first.

Comment 28 lirui 2011-10-31 06:45:19 UTC
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.

Comment 29 Josua Dietze 2011-10-31 11:25:24 UTC
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.

Comment 30 Josua Dietze 2011-10-31 23:08:07 UTC
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.

Comment 31 lirui 2011-11-03 02:23:31 UTC
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!

Comment 32 Josua Dietze 2011-11-03 23:22:47 UTC
Lirui, I could only tell you what is written on top of the bug report page ...

Comment 33 Juan Francisco Fernández 2011-11-14 12:48:01 UTC
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.

Comment 34 Josua Dietze 2011-11-14 18:17:15 UTC
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.

Comment 35 Juan Francisco Fernández 2011-11-14 18:24:08 UTC
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.

Comment 36 Juan Francisco Fernández 2011-11-15 13:01:48 UTC
Created attachment 533765 [details]
usb_modeswitch log for ZTE MF626

I have installed usb_modeswitch from upstream.

Comment 37 Juan Francisco Fernández 2011-11-15 13:10:49 UTC
Created attachment 533766 [details]
dmesg log for ZTE MF626 dongle using upstream usb_modeswitch

Comment 38 Juan Francisco Fernández 2011-11-15 13:11:28 UTC
Hi Josua, I have installed the upstream package but the unreliability issue persists. I have attached my usb_modeswitch log and dmesg message.

Thanks!

Comment 39 Josua Dietze 2011-11-15 13:26:22 UTC
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?

Comment 40 Juan Francisco Fernández 2011-11-15 13:47:07 UTC
Yep, I don't have been promted to enter the pin and the broadban connections is not shown on NetworkManager.

Comment 41 Josua Dietze 2011-11-15 15:12:26 UTC
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.

Comment 42 Juan Francisco Fernández 2011-11-15 16:12:09 UTC
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?

Comment 43 lirui 2011-11-16 01:27:46 UTC
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.

Comment 44 Juan Francisco Fernández 2011-11-16 07:18:26 UTC
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

Comment 45 Juan Francisco Fernández 2011-11-16 07:20:54 UTC
Created attachment 533918 [details]
Output from command lsusb -v -d 19d2:0066 as superuser after usb_switchmode.

Comment 46 Juan Francisco Fernández 2011-11-16 07:34:00 UTC
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.

Comment 47 lirui 2011-11-16 08:02:28 UTC
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.

Comment 48 Juan Francisco Fernández 2011-11-16 10:58:08 UTC
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

Comment 49 lirui 2011-11-17 01:16:53 UTC
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

Comment 50 Juan Francisco Fernández 2011-11-17 07:22:15 UTC
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.

Comment 51 lirui 2011-11-29 06:25:58 UTC
(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?

Comment 52 lirui 2011-12-06 06:51:56 UTC
Dear Josua,
    I advise you that do not update and add ZTE product ID on your software before this bug fix.
Thank you!

Comment 53 lirui 2011-12-19 10:38:01 UTC
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.

Comment 54 lirui 2011-12-19 10:39:09 UTC
Created attachment 548536 [details]
fujitsu's computer

Comment 55 lirui 2011-12-19 10:39:34 UTC
Created attachment 548537 [details]
dell's computer

Comment 56 Josua Dietze 2011-12-19 18:25:16 UTC
Lirui, what about the usb_modeswitch version on the Dell? Unchanged Fedora package or modified/upstream?

Comment 57 lirui 2011-12-20 01:25:39 UTC
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!

Comment 58 lirui 2011-12-20 07:45:55 UTC
Created attachment 548772 [details]
usb_modeswitch_for_dell_after_crash

Comment 59 lirui 2011-12-20 07:46:49 UTC
Created attachment 548773 [details]
usb_modeswitch_for_fujitsu_after_crash

Comment 60 lirui 2011-12-20 07:56:29 UTC
Created attachment 548777 [details]
this_log_show_after_kernel_crash_fujitsu_ok

Comment 61 lirui 2011-12-20 09:00:54 UTC
Created attachment 548796 [details]
dmesg_fc15_2.6.38_after_kernel_crash_dell

Comment 62 lirui 2012-01-16 12:07:40 UTC
Dear Josua,

    How are you?any update?

Comment 63 Josua Dietze 2012-01-16 13:39:40 UTC
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.

Comment 64 lirui 2012-01-17 01:48:46 UTC
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!

Comment 65 lirui 2012-01-17 01:51:07 UTC
Fedora package maintainers:
    Please pay attention to this bug and correct the error as soon as possible!
Thank you!

Comment 66 Will Woods 2012-01-18 19:27:22 UTC
..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.

Comment 67 Josua Dietze 2012-01-18 20:10:57 UTC
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.

Comment 68 Huzaifa S. Sidhpurwala 2012-01-26 06:00:51 UTC
usb_modeswitch-1.2.2-2 should fix this issue, can someone test and let me know if it works?

Comment 69 lirui 2012-02-02 01:25:47 UTC
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.

Comment 70 Kamil Páral 2012-09-17 16:11:35 UTC
Removing CommonBugs tag, Fedora 16 is long time released.

Comment 71 Fedora End Of Life 2013-01-16 15:09:47 UTC
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

Comment 72 Fedora End Of Life 2013-02-13 16:30:55 UTC
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.


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