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:
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.
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.
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
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.
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
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.
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.
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
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.
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.
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.
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.
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.
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.
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
(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.
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.
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 ~]$
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
Re-opning as this still occurs on F18 and remains unfixed.
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.
Have you looked at WvDial?
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.
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.