Bug 718131 - Full Pantech UML290 support for 3G & 4G
Full Pantech UML290 support for 3G & 4G
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: ModemManager (Show other bugs)
18
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-01 02:30 EDT by Arnold Wang
Modified: 2014-02-05 17:41 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 17:41:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Arnold Wang 2011-07-01 02:30:21 EDT
Description of problem:
After I upgraded to Fedora 15, I can't connect to Verizon wireless network any more. My USB modem is Pantech UML290. The system reconized the hardware, however it won't connect to the network. It worked in Fedora 14, after I manually specify the APNs. I can't do this any more in F15. 

Version-Release number of selected component (if applicable):
NetworkManager-0.8.9997-4.git20110620.fc15.x86_64

How reproducible:
Try to connect to Verizon wireless network.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
It never connects. 
 
Expected results:
Connect to the network.

Additional info:
Comment 1 Arnold Wang 2011-07-01 02:34:38 EDT
The followings are from /var/log/messages:
Jun 30 23:30:42 arnoldw dbus: [system] Successfully activated service 'org.freedesktop.PackageKit'
Jun 30 23:33:24 arnoldw NetworkManager[2828]: <info> Activation (ttyACM0) starting connection 'LTE connection 1'
Jun 30 23:33:24 arnoldw NetworkManager[2828]: <info> (ttyACM0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jun 30 23:33:24 arnoldw NetworkManager[2828]: <info> Activation (ttyACM0) Stage 1 of 5 (Device Prepare) scheduled...
Jun 30 23:33:24 arnoldw NetworkManager[2828]: <info> Activation (ttyACM0) Stage 1 of 5 (Device Prepare) started...
Jun 30 23:33:24 arnoldw NetworkManager[2828]: <info> Activation (ttyACM0) Stage 1 of 5 (Device Prepare) complete.
Comment 2 Brad Scalio 2011-07-12 11:07:29 EDT
You can specify the APNs by running nm-connection-settings however even still I cannot connect with this same device using NetworkManager-0.8.9997-5.git20110702.fc15.x86_64 I get similar responses as above (see below) ... other mobile broadband devices work, but the USB ones appear to have issues.



Jul 12 10:58:07 hp6930p kernel: [  747.385277] usb 2-1: new high speed USB device using ehci_hcd and address 2
Jul 12 10:58:07 hp6930p kernel: [  747.501673] usb 2-1: New USB device found, idVendor=106c, idProduct=3718
Jul 12 10:58:07 hp6930p kernel: [  747.501683] usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=0
Jul 12 10:58:07 hp6930p kernel: [  747.501690] usb 2-1: Product: PANTECH UML290
Jul 12 10:58:07 hp6930p kernel: [  747.501696] usb 2-1: Manufacturer: Pantech, Incorporated
Jul 12 10:58:07 hp6930p mtp-probe: checking bus 2, device 2: "/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1"
Jul 12 10:58:07 hp6930p mtp-probe: bus: 2, device: 2 was not an MTP device
Jul 12 10:58:07 hp6930p kernel: [  747.873162] cdc_acm 2-1:1.0: ttyACM0: USB ACM device
Jul 12 10:58:07 hp6930p kernel: [  747.873996] usbcore: registered new interface driver cdc_acm
Jul 12 10:58:07 hp6930p kernel: [  747.873998] cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
Jul 12 10:58:07 hp6930p kernel: [  747.933313] usbcore: registered new interface driver usbserial
Jul 12 10:58:07 hp6930p kernel: [  747.933590] USB Serial support registered for generic
Jul 12 10:58:07 hp6930p kernel: [  747.933912] usbcore: registered new interface driver usbserial_generic
Jul 12 10:58:07 hp6930p kernel: [  747.933914] usbserial: USB Serial Driver core
Jul 12 10:58:07 hp6930p modem-manager[1115]: <info>  (ttyACM0) opening serial port...
Jul 12 10:58:07 hp6930p kernel: [  747.944068] USB Serial support registered for qcaux
Jul 12 10:58:07 hp6930p kernel: [  747.944089] qcaux 2-1:1.2: qcaux converter detected
Jul 12 10:58:07 hp6930p kernel: [  747.944185] usb 2-1: qcaux converter now attached to ttyUSB0
Jul 12 10:58:07 hp6930p kernel: [  747.944199] usbcore: registered new interface driver qcaux
Jul 12 10:58:07 hp6930p modem-manager[1115]: <info>  (ttyUSB0) opening serial port...
Jul 12 10:58:10 hp6930p modem-manager[1115]: <info>  (ttyACM0) closing serial port...
Jul 12 10:58:10 hp6930p modem-manager[1115]: <info>  (ttyACM0) serial port closed
Jul 12 10:58:10 hp6930p modem-manager[1115]: <info>  (ttyACM0) opening serial port...
Jul 12 10:58:10 hp6930p modem-manager[1115]: <info>  (Generic): CDMA modem /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1 claimed port ttyACM0
Jul 12 10:58:10 hp6930p modem-manager[1115]: <info>  (ttyACM0) closing serial port...
Jul 12 10:58:10 hp6930p modem-manager[1115]: <info>  (ttyACM0) serial port closed
Jul 12 10:58:19 hp6930p modem-manager[1115]: <info>  (ttyUSB0) closing serial port...
Jul 12 10:58:19 hp6930p modem-manager[1115]: <info>  (ttyUSB0) serial port closed
Jul 12 10:58:19 hp6930p modem-manager[1115]: <info>  (ttyUSB0) opening serial port...
Jul 12 10:58:22 hp6930p modem-manager[1115]: <info>  (ttyUSB0) closing serial port...
Jul 12 10:58:22 hp6930p modem-manager[1115]: <info>  (ttyUSB0) serial port closed
Jul 12 10:58:22 hp6930p modem-manager[1115]: <info>  (Generic): CDMA modem /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1 claimed port ttyUSB0
Jul 12 10:58:22 hp6930p NetworkManager[1002]: <warn> (ttyACM0): failed to look up interface index
Jul 12 10:58:22 hp6930p NetworkManager[1002]: <info> (ttyACM0): new CDMA/EVDO device (driver: 'cdc_acm' ifindex: -1)
Jul 12 10:58:22 hp6930p NetworkManager[1002]: <info> (ttyACM0): exported as /org/freedesktop/NetworkManager/Devices/2
Jul 12 10:58:22 hp6930p NetworkManager[1002]: <info> (ttyACM0): now managed
Jul 12 10:58:22 hp6930p NetworkManager[1002]: <info> (ttyACM0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Jul 12 10:58:22 hp6930p NetworkManager[1002]: <info> (ttyACM0): deactivating device (reason: 2).
Jul 12 10:58:22 hp6930p NetworkManager[1002]: <info> (ttyACM0): device state change: unavailable -> disconnected (reason 'none') [20 30 0]
Jul 12 10:58:55 hp6930p NetworkManager[1002]: <info> Activation (ttyACM0) starting connection 'Verizon'
Jul 12 10:58:55 hp6930p NetworkManager[1002]: <info> (ttyACM0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jul 12 10:58:55 hp6930p NetworkManager[1002]: <info> Activation (ttyACM0) Stage 1 of 5 (Device Prepare) scheduled...
Jul 12 10:58:55 hp6930p NetworkManager[1002]: <info> Activation (ttyACM0) Stage 1 of 5 (Device Prepare) started...
Jul 12 10:58:55 hp6930p NetworkManager[1002]: <info> Activation (ttyACM0) Stage 1 of 5 (Device Prepare) complete.
Jul 12 10:58:55 hp6930p modem-manager[1115]: <info>  (ttyACM0) opening serial port...
Jul 12 10:58:55 hp6930p modem-manager[1115]: <info>  Modem /org/freedesktop/ModemManager/Modems/0: state changed (disabled -> enabling)
Jul 12 10:58:56 hp6930p modem-manager[1115]: <info>  (ttyUSB0) opening serial port...
Jul 12 10:58:56 hp6930p modem-manager[1115]: <info>  Modem /org/freedesktop/ModemManager/Modems/0: state changed (enabling -> enabled)
Jul 12 10:58:56 hp6930p NetworkManager[1002]: <info> WWAN now enabled by management service
Jul 12 10:59:56 hp6930p NetworkManager[1002]: <warn> CDMA connection failed: (32) No service
Jul 12 10:59:56 hp6930p NetworkManager[1002]: <info> (ttyACM0): device state change: prepare -> failed (reason 'none') [40 120 0]
Jul 12 10:59:56 hp6930p NetworkManager[1002]: <warn> Activation (ttyACM0) failed.
Comment 3 Brad Scalio 2011-07-12 21:28:13 EDT
I have verified the USB modem on a Fedora 14 box, and it works just fine, as well as on a Windows PC, but even a PPP dial out fails, and it is failing on the carrier detect, which usually means problems with the modem or account (cdma plan), but like I said, it works on F14 and WXP just fine


[root@hp6930p dev]# wvdial
--> WvDial: Internet dialer version 1.61
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK
--> Sending: AT+CGDCONT=1,"IP","vzwinternet"
AT+CGDCONT=1,"IP","vzwinternet"
OK
--> Modem initialized.
--> Sending: ATDT#777
--> Waiting for carrier.
ATDT#777
ERROR
--> Invalid dial command.
--> Disconnecting at Tue Jul 12 21:25:55 2011
Comment 4 Dan Williams 2011-07-18 20:12:21 EDT
This modem is "special" in some ways, as it exposes both a GSM-style and a CDMA-style command set.  Unfortunately, the GSM-style (which you see being used here) only allows connection to the 4G LTE network; when using these you cannot fall back to EVDO in 3G areas at all.  We need some additional work in ModemManager to make the UML290 work better, and some of that work is reverse engineering the proprietary command set the modem actually uses in Windows so that it works seamlessly in Linux as well.
Comment 5 Brad Scalio 2011-07-18 20:31:12 EDT
If you need anything let me know and I would be happy to provide it, but it sounds like you guys know what needs to be done.

Regardless, it works just fine in F14 ... I always had the issue that if I did not have "4G" LTE I couldn't "fall back" to EVDO/3G ... but at least the LTE connections worked, now neither works in the new ModemManager ... would be nice to at least get the LTE connection back ;-)

Thanks

Brad
Comment 6 Dan Williams 2011-08-02 12:15:25 EDT
There's a few issues with the UML290 (I have one, and I'm paying $50 a month so I care).  First is that the device is a CDMA/LTE combo device, but the command sets you use to initiate CDMA or LTE connections differ.  As a user, you shouldn't have to care about whether you are connecting to the LTE network or the CDMA network, and in ModemManager we need to be able to handle what network you're registered with anyway, which takes some work.

Second, the UML290 cannot current roam between LTE and EVDO on Linux without tearing down the connection and reconnecting it.  That really sucks, but I'm hopeful that reverse engineering the proprietary WMC protocol that the UML290 talks, in conjunction with exposing it's native IP interface, will make that work seamlessly.

More details here:

http://blogs.gnome.org/dcbw/2011/06/17/the-incredible-magical-pantech-uml290/


Note that when dialing CDMA/EVDO (ie, ATDT#777) you do not need to specify the APN, since APNs are not used with CDMA networks.  You simply need to ensure the modem is registered (AT+CAD? may show that) and dial #777.

For LTE, you need to do the standard GSM-style setup, including AT+CGDCONT to set the APN (you'll want to use the "IPV4V6" PDP context type when doing so), ensure the device is registered with AT+CREG? (a report of 1 or 5 means registered, other values mean it's not registered), and then dial with ATD***1#.  When the modem is registered on the LTE network, it's unlikely you'll be able to use #777 to dial CDMA/EVDO.

Second, if you want to use the CDMA/EVDO part if you're in a CDMA/EVDO area, you'll need to (a) activate the modem, and (b) switch the EVDO protocol from eHRPD to HRPD, otherwise you wont' be able to make a connection at all.

The switching thing is the problem, and the reason you can't roam between right now, and that's what we're hoping the proprietary WMC commands plus the network interface will fix.  But that's going to take a bit more reverse engineering.  And until that point, ModemManager likely won't fully support the UML290 because we'd rather not put in ugly hacks, we'd rather do it right the first time.
Comment 7 John Langford 2011-08-04 16:01:54 EDT
I just got a pantech, and am having identical difficulties to the above: the pantech is deadweight under FC15.

As far as I can tell, usb detects it ok, nm detects it, I tell it the provider is Verizon, and then it fails to connect.  I understand seamless EVDO/LTE isn't working, but exposing at least one working interface (and possibly both) would be good.  This is with NetworkManager-0.8.9997-6.
Comment 8 John Langford 2011-08-04 16:27:29 EDT
I tried Brad's wvdial script above (as well as others).  Nothing seems to be working at the moment.  I get:
--> Sending: AT+CGDCONT=1,"IP","vzwinternet"
AT+CGDCONT=1,"IP","vzwinternet"
ERROR
--> Bad init string
Comment 9 Brad Scalio 2011-08-04 17:29:34 EDT
I haven't had time to try various setting for wvdial using standard ETSI 27.007 GSM-style AT commands like AT+CGDCONT and ATD#99* and such.  I assume dialing directly *should* work, if someone has a better grasp of such methods feel free and I can test it out but yes, the modem is essentially a brick in F15 ... at some point I will try downgrading NM and dependencies to F14 or simply revert back to F14 (and just as I was getting used to Gnome Shell).

While I understand the rationale and resource issues involved with reverse engineering support, like John said above, at least the CDMA/EVDO was working under F14 baseline, now neither is supported.  But thanks for at least entertaining this bug.
Comment 10 John Langford 2011-08-04 20:30:11 EDT
I downgraded to F14.  The modem was autodetected by nm, and specifying 'vzwinternet' as here: http://www.pagey.info/2011/01/using-pantech-uml290-on-ubuntu-linux.html made it work.  Presumably, this is only 4G support, which has limited coverage.

When I use nm-connection-editor, it shows the number as *99#, no username, no password, APN: vzwinternet, no Network ID, Type: Any, Roaming allowed, no PIN.

There are still problems though.  
(1) When I disconnect then attempt to reconnect, network manager notifies "Disconnected...".  The only way to reconnect is to remove the modem and reinsert it.  This is NetworkManager-0.8.4-1.
(2) I've been unable to enable 3G mode via this wvdial script (and comments).
http://ubuntuforums.org/archive/index.php/t-1656425.html

The modem doesn't appear to reset into the initial state cleanly _and_ it's slow initializing, so it's difficult to cargocult the script.
Comment 11 Brad Scalio 2011-08-15 07:26:46 EDT
I have always noticed the behavior John sees above with the device in F14.  I often have to reseat the card once disconnecting and reconnecting.
Comment 12 Dan Williams 2012-01-20 12:04:29 EST
As an update, I'm still working on this.  There are two parts:

1) WMC reverse engineering - I spent a bunch of time on this recently, and figured out a few more things like access technology reporting and such.  This part is going well but isn't as critical to the UML290, it's more for the Verizon Global modems like the UMW190.

2) It turns out we need a kernel QMI driver for the UML290's network interface.  There's some work going on with this upstream, but then we need to also work on a userspace QMI library to make sure everything works smoothly.

This modem is somewhat unfortunate because it uses a combination of both WMC and QMI and we need *both* before the modem can work seamlessly without hacks.  We also need both before you can transparently hand off between EVDO and LTE.  There's no good solution for Verizon LTE right now until these sorts of things get solved.

The LG VL600 has some "special" characteristics as well that make it less suitable until it's command set gets reverse engineered, and the Verizon/Novatel 551L has a better AT command set but is less friendly in other ways.
Comment 13 Wilbur 2012-01-25 19:12:42 EST
This sounds like the same problem reported in "Bug 668628", gnome. The Pantech 290 modem works fine under older nm-applet releases like 0.8.1 but not at all under later 64bit releases.

I have tried and failed on 64bit:
Mint 12
Mint Debian xfce
Ubuntu 
Xubuntu 

Success on:
Mint 10
Ubuntu 10
Xubutu 10
Puppy linux and a number of others.

This seems to be a basic failure in the later release code.
Comment 14 Wilbur 2012-01-25 19:22:41 EST
I have read the comments by Dan Williams and appreciate the fine work but the problem did not exist in earlier code so the solution must have already been developed and implemented. What about just putting the old code back in place and getting things working again for the moment? The code in 0.8.1 may not have been ideal but it worked.
Comment 15 Wilbur 2012-01-31 15:59:58 EST
Four ways I have tried to connect using nm-applet 0.8.4:
1. nm-applet   - Failed
2. pppd        - Failed
3. wvdial      - Failed
4. nmcli       - Failed

Here is some data from the same computer using nm-applet 0.8.1 and connected:

64bit Linux version 2.6.35-30-generic 

Network Manager version 0.8.1

devices:
T:  Bus=06 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=02(commc) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=106c ProdID=3718 Rev=00.00
S:  Manufacturer=Pantech, Incorporated
S:  Product=PANTECH UML290
C:  #Ifs= 6 Cfg#= 1 Atr=c0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=01 Driver=cdc_acm
I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=fd Prot=ff Driver=(none)
I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=fe Prot=ff Driver=(none)
I:  If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=f0 Prot=ff Driver=(none)

nmcli:
DEVICE     TYPE              STATE       
eth0       802-3-ethernet    unavailable 
ttyACM0    gsm               connected   

NetworkManager Tool

State: connected

- Device: eth0 -----------------------------------------------------------------
  Type:              Wired
  Driver:            r8169
  State:             unavailable
  Default:           no
  HW Address:        48:5B:39:31:B0:FD

  Capabilities:
    Carrier Detect:  yes
    Speed:           10 Mb/s

  Wired Properties
    Carrier:         off

- Device: ttyACM0  [verizon 4g LTE] --------------------------------------------
  Type:              Mobile Broadband (GSM)
  Driver:            cdc_acm
  State:             connected
  Default:           yes

  Capabilities:

  IPv4 Settings:
    Address:         10.161.28.50
    Prefix:          32 (255.255.255.255)
    Gateway:         10.64.64.64

    DNS:             66.174.92.14
    DNS:             69.78.96.14

- VPN:  [nlfreevpn *] ----------------------------------------------------------
  State:             connected
  Default:           no

dmesg:
[    0.000000] console [tty0] enabled
[    8.325714] cdc_acm 6-2.1:1.0: ttyACM0: USB ACM device
Comment 16 Andrew Hecox 2012-04-29 11:28:38 EDT
(In reply to comment #12)

> 
> The LG VL600 has some "special" characteristics as well that make it less
> suitable until it's command set gets reverse engineered, and the
> Verizon/Novatel 551L has a better AT command set but is less friendly in other
> ways.

is there a related BZ on the Novatel 551L issue? I can spin one up but don't want to dup. Trying to run on RHEL 6.2.
Comment 17 JYundt 2012-06-05 16:02:58 EDT
I tried using my UML290 on a fresh Fedora 17 install.  Unfortunately, I'm having similar problems when trying to connect.

I'll post logs shortly.
Comment 18 JYundt 2012-06-05 16:15:27 EDT
Whoops, I don't think NM is even detecting the modem:

/var/log/messages: 

Jun  5 16:06:30 cctssysup-1dbx kernel: [11373.735035] usb 2-5: new high-speed USB device number 4 using ehci_hcd
Jun  5 16:06:30 cctssysup-1dbx kernel: [11373.852966] usb 2-5: New USB device found, idVendor=106c, idProduct=3718
Jun  5 16:06:30 cctssysup-1dbx kernel: [11373.852975] usb 2-5: New USB device strings: Mfr=3, Product=2, SerialNumber=0
Jun  5 16:06:30 cctssysup-1dbx kernel: [11373.852983] usb 2-5: Product: PANTECH UML290
Jun  5 16:06:30 cctssysup-1dbx kernel: [11373.852988] usb 2-5: Manufacturer: Pantech, Incorporated
Jun  5 16:06:30 cctssysup-1dbx kernel: [11373.854922] cdc_acm 2-5:1.0: ttyACM0: USB ACM device
Jun  5 16:06:30 cctssysup-1dbx kernel: [11373.856153] qcaux 2-5:1.2: qcaux converter detected
Jun  5 16:06:30 cctssysup-1dbx kernel: [11373.856385] usb 2-5: qcaux converter now attached to ttyUSB0
Jun  5 16:06:30 cctssysup-1dbx kernel: [11373.856592] qcaux 2-5:1.3: qcaux converter detected
Jun  5 16:06:30 cctssysup-1dbx kernel: [11373.856795] usb 2-5: qcaux converter now attached to ttyUSB1
Jun  5 16:06:30 cctssysup-1dbx kernel: [11373.856989] qcaux 2-5:1.4: qcaux converter detected
Jun  5 16:06:30 cctssysup-1dbx kernel: [11373.857269] usb 2-5: qcaux converter now attached to ttyUSB2
Jun  5 16:06:30 cctssysup-1dbx mtp-probe: checking bus 2, device 4: "/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-5"
Jun  5 16:06:30 cctssysup-1dbx mtp-probe: bus: 2, device: 4 was not an MTP device



[root@cctssysup-1dbx ~]# nmcli  dev
DEVICE     TYPE              STATE        
wlan0      802-11-wireless   connected    
eth0       802-3-ethernet    connected    

[yundtj@cctssysup-1dbx ~]$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 004 Device 002: ID 08ff:2810 AuthenTec, Inc. AES2810
Bus 002 Device 004: ID 106c:3718 Curitel Communications, Inc. 
[yundtj@cctssysup-1dbx ~]$ lsusb -vv -d 106c:3718

Bus 002 Device 004: ID 106c:3718 Curitel Communications, Inc. 
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x106c Curitel Communications, Inc.
  idProduct          0x3718 
  bcdDevice            0.00
  iManufacturer           3 
  iProduct                2 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          166
    bNumInterfaces          6
    bConfigurationValue     1
    iConfiguration          1 
    bmAttributes         0xc0
      Self Powered
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Call Management:
        bmCapabilities       0x03
          call management
          use DataInterface
        bDataInterface          1
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    253 
      bInterfaceProtocol    255 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        4
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    254 
      bInterfaceProtocol    255 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        5
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    240 
      bInterfaceProtocol    255 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x87  EP 7 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
[yundtj@cctssysup-1dbx ~]$ cat /etc/redhat-release 
Fedora release 17 (Beefy Miracle)
[yundtj@cctssysup-1dbx ~]$ uname -a
Linux cctssysup-1dbx 3.3.7-1.fc17.i686.PAE #1 SMP Mon May 21 22:42:05 UTC 2012 i686 i686 i386 GNU/Linux
[yundtj@cctssysup-1dbx ~]$
Comment 19 Fedora End Of Life 2012-08-07 12:01:59 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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" (top right of this page) 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 20 Dan Mashal 2013-01-09 05:09:51 EST
Re-opning as this still occurs on F18 and remains unfixed.
Comment 21 Dan Williams 2013-03-08 10:24:47 EST
We've made some progress with the UML290 in ModemManager upstream by using the device's native QMI protocol, though it still doesn't work correctly due to some device issues that need to be debugged.
Comment 22 Dan Mashal 2013-03-10 00:11:09 EST
Have you looked at WvDial?
Comment 23 Fedora End Of Life 2013-12-21 09:56:22 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. 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 '18'.

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 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 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  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

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.
Comment 24 Fedora End Of Life 2014-02-05 17:41:51 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

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.