So upstream is nak'ing the patch saying that the proper fix is to use usb-modeswitch.  Have you tried that?  Though it doesn't look like it is available for RHEL-6.

Cheers,
Don

Hi Don,
I can build usb-modeswitch myself but I don't really need that. Once the device appears as CD-ROM it can be ejected and then it switches into modem mode. 

The original issue reported was that the modem device never appeared as CD-ROM with the GA kernel and hence it cannot be switched into modem mode. See the irc discussion in comment #0. 

Now with the test kernel provided in comment #2 everything works without usb_modeswitch. Looks like the proper fix is somewhere in between.

Can you comment out the udev rule in /lib/udev/rules.d/61-option-modem-modeswitch.rules pertaining to the device id 19d2 (at the bottom) and try to reconnect.  Then you might be able to manually eject the device.

Currently I think udev tries to use the old modem-modeswitch app, which may cause problems.

Cheers,
Don

Hi Don,
I've commented out the entry for my modem in the udev rules file. The result is this:

Tested with kernel 2.6.32-71.7.1.el6.i686

When I first plugin the device lsusb reports:
Bus 001 Device 008: ID 19d2:2000 ONDA Communication S.p.A. ZTE MF627/MF628/MF628+/MF636+ HSDPA/HSUPA


Then after a while it initializes (the led on the device turns from red to blue meaning it registered on the GSM network). lsusb reports:
Bus 001 Device 005: ID 19d2:0063 ONDA Communication S.p.A. 



This is without usb_modeswitch installed.

This is a prepaid card which expired the other day. I will re-charge it and try to connect to the Internet once again.

Hi Don,
I've confirmed that I can connect to the Internet after re-charging the pre-paid card. So my previous comment stays: 

With kernel 2.6.32-71.7.1.el6.i686 and the modem line in /lib/udev/rules.d/61-option-modem-modeswitch.rules disabled the device automatically switches into modem mode after a while. 

I also found that 61-mobile-action.rules will call /bin/eject on the device which will make it switch into the right mode. There's also the 77-mm-zte-port-types.rules file (from ModemManager), which I'm not sure what it does.

For what it's worth, I'm seeing the same thing with a Virgin Mobile MiFi 2200.

It's presented as a USB Mass Storage device at first (idVendor=1410, idProduct=5020).  If I eject it, it switches to a USB mobile broadband device (idVendor=1410, idProduct=6000) and works great.

Simply hitting the eject button is a totally fine workaround, but it would be much more elegant and intuitive to be able to skip the CD part and jump right to acting like a USB mobile broadband device right away.

(In reply to comment #10)
> For what it's worth, I'm seeing the same thing with a Virgin Mobile MiFi 2200.
> 
> It's presented as a USB Mass Storage device at first (idVendor=1410,
> idProduct=5020).  If I eject it, it switches to a USB mobile broadband device
> (idVendor=1410, idProduct=6000) and works great.
> 
> Simply hitting the eject button is a totally fine workaround, but it would be
> much more elegant and intuitive to be able to skip the CD part and jump right
> to acting like a USB mobile broadband device right away.

David,

Can you add the following line to the bottom of our /lib/udev/rules.d/61-mobile-action.rules file

ACTION=="add", ENV{ID_CDROM}=="1", ENV{ID_VENDOR_ID}=="1410", ENV{ID_MODEL_ID}=="5020", RUN+="/usr/bin/eject %k"

And let me know if that worked seamlessly for you?

Cheers,
Don

(In reply to comment #9)
> Hi Don,
> I've confirmed that I can connect to the Internet after re-charging the
> pre-paid card. So my previous comment stays: 
> 
> With kernel 2.6.32-71.7.1.el6.i686 and the modem line in
> /lib/udev/rules.d/61-option-modem-modeswitch.rules disabled the device
> automatically switches into modem mode after a while. 
> 
> I also found that 61-mobile-action.rules will call /bin/eject on the device
> which will make it switch into the right mode. There's also the
> 77-mm-zte-port-types.rules file (from ModemManager), which I'm not sure what it
> does.

Thanks Alexander.

I am going to move this bz over to the udev component and suggest that maintainer remove the following line from /lib/udev/61-option-modem-modeswitch.rules:

ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="2000", RUN+="modem-modeswitch -v 0x%s{idVendor} -p 0x%s{idProduct} -t option-zerocd"

Thanks,
Don

Changing to udev component.  The problems described in this bz can be fixed by updating the udev rules.

Cheers,
Don

(In reply to comment #11)
> (In reply to comment #10)
> > For what it's worth, I'm seeing the same thing with a Virgin Mobile MiFi 2200.
> > 
> > It's presented as a USB Mass Storage device at first (idVendor=1410,
> > idProduct=5020).  If I eject it, it switches to a USB mobile broadband device
> > (idVendor=1410, idProduct=6000) and works great.
> > 
> > Simply hitting the eject button is a totally fine workaround, but it would be
> > much more elegant and intuitive to be able to skip the CD part and jump right
> > to acting like a USB mobile broadband device right away.
> 
> David,
> 
> Can you add the following line to the bottom of our
> /lib/udev/rules.d/61-mobile-action.rules file
> 
> ACTION=="add", ENV{ID_CDROM}=="1", ENV{ID_VENDOR_ID}=="1410",
> ENV{ID_MODEL_ID}=="5020", RUN+="/usr/bin/eject %k"
> 
> And let me know if that worked seamlessly for you?
> 
> Cheers,
> Don

Seamlessly is indeed the operative word here Don.  It worked PERFECTLY.  No need to explicitly eject since your rule does the ejection for me.  All I needed to do was the USB insertion and in about 30 seconds it showed up in NetworkManager.  Thanks Don!

One minor (minor) suggestion for improvement:  Would there be any way to shorten the 30 seconds or at least provide some user feedback that something was going on?  Someone less patient may think it didn't work if relatively immediate feedback isn't provided.  Perhaps that's an RFE for someone else?

Anyhow, THANK YOU Don!!!

Hi David,
the 30 sec (or so) delay is coming from the initialization of the GSM modem. In my particular case the modem has a led indicating that it's initializing and attempting to connect to the network. The led goes through several different colors meaning different things.

If the device is sending a status notification that it's still initializing then IMHO it would be best to file RFE against NetworkManager to detect this notification and visually alert the user.

(In reply to comment #15)
> Hi David,
> the 30 sec (or so) delay is coming from the initialization of the GSM modem. In
> my particular case the modem has a led indicating that it's initializing and
> attempting to connect to the network. The led goes through several different
> colors meaning different things.
> 
> If the device is sending a status notification that it's still initializing
> then IMHO it would be best to file RFE against NetworkManager to detect this
> notification and visually alert the user.

Done!

https://bugzilla.redhat.com/show_bug.cgi?id=664502

Sounds like a doable fix, but doesn't qualify as a blocking issue for RHEL-6.1, so i moved it to 6.2 and approved it from devel side.

Thanks & regards, Phil

*** Bug 715009 has been marked as a duplicate of this bug. ***

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
The Vodafone K3565-Z 3G modem was not working on RHEL6, because udev called modem-modeswitch on the device. This caused, that the virtual cdrom (the devices provides first) could not be ejected, to get to the modem functionality.
The new udev version does not call modem-modeswitch for this device and instead automatically eject the cdrom.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,2 +1 @@
-The Vodafone K3565-Z 3G modem was not working on RHEL6, because udev called modem-modeswitch on the device. This caused, that the virtual cdrom (the devices provides first) could not be ejected, to get to the modem functionality.
+Previously, a udev rule used the modem-modeswitch callout on the Vodafone K3565-Z 3G modem. As a consequence, a medium in a virtual CD-ROM drive could not be ejected to activate the modem functionality. With this update, the modem-modeswitch callout is no longer used for this device and a medium is automatically ejected instead, thus fixing this bug.-The new udev version does not call modem-modeswitch for this device and instead automatically eject the cdrom.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1649.html

*** Bug 684297 has been marked as a duplicate of this bug. ***