Bug 515412 - NetworkManager does not recognize ZTE EVDO USB Modem as a device with "mobile broadband capabilties"
Summary: NetworkManager does not recognize ZTE EVDO USB Modem as a device with "mobile...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 526586 (view as bug list)
Depends On: 519332
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-04 06:32 UTC by steve
Modified: 2010-12-05 06:39 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-05 06:39:23 UTC


Attachments (Terms of Use)
relevant section of /var/log/messages (2.74 KB, text/plain)
2009-08-04 06:32 UTC, steve
no flags Details
output of lsusb with device plugged in (630 bytes, text/plain)
2009-08-04 06:34 UTC, steve
no flags Details
NM_SERIAL_DEBUG=1 /usr/sbin/NetworkManager --no-daemon (6.94 KB, text/plain)
2009-08-06 05:52 UTC, steve
no flags Details
dmesg output (1.25 KB, text/plain)
2009-08-06 05:55 UTC, steve
no flags Details
NM_SERIAL_DEBUG=1 /usr/sbin/NetworkManager --no-daemon (7.50 KB, text/plain)
2009-08-27 15:02 UTC, steve
no flags Details
relevant section of /var/log/messages (6.10 KB, text/plain)
2009-08-27 15:03 UTC, steve
no flags Details
/var/log/message reffered to in Comment #31 (12.93 KB, text/plain)
2009-12-12 11:25 UTC, steve
no flags Details
No wvdial needed if I wait for 3 mins. before restarting NM (Comment #33) (9.03 KB, text/plain)
2009-12-17 14:41 UTC, steve
no flags Details

Description steve 2009-08-04 06:32:38 UTC
Created attachment 356104 [details]
relevant section of /var/log/messages

Description of problem:

I have a ZTE EVDO USB Modem which has been reported to work on linux. However on my F11 system NetworkManager does not offer to configure this device and reports the following message in '/var/log/messages':

Aug  4 11:05:02 laptop NetworkManager: <info>  (ttyUSB0): ignoring due to lack of mobile broadband capabilties

Longer description of the problem in Additional info below.

Version-Release number of selected component (if applicable):
NetworkManager-0.7.1-8.git20090708.fc11.x86_64


How reproducible:
Always.


Steps to Reproduce:
1. Insert ZTE USB modem
2. Notice that the system recognizes this as an external usb cdrom
3. Use usb_modeswitch to disassociate the device as an external usb cdrom
4. modprobe -v usbserial vendor=0x19d2 product=0xfff6
5. Notice that NetworkManager reports ..

Aug  4 11:05:02 laptop NetworkManager: <info>  (ttyUSB0): ignoring due to lack of mobile broadband capabilties

Actual results:
NetworkManager does not recognize the device.

Expected results:
NetworkManager should recognize the device as a Mobile Broadband device and offer the option to 'Create a new ....connection' as it does with other GSM/CDMA/... devices.


Additional info:

This device is one of the new EVDO devices launched in India. It has been reported that this works with linux as long as it is configured as a USB serial device.

http://lug-iitd.org/EvDO_on_Linux
http://www.tuxhat.com/linux/reliance-netconnect-broadband-on-linux/
http://www.google.com/search?q=zte+evdo+linux

All of the howtos/blog posts I have seen however appear to suggest using
wvdial. Now wvdial itself seems broken in F11 (that's another bug altogether,
I'll do some more investigation before filing it, but just to avoid any doubts,
wvdial does not even work with my GPRS connection whereas NetworkManager does).

Most howtos go along the lines ...
1. Insert the device
2. Run usb_modeswitch or rmmod usb_storage && modprobe usbserial vendor=xx product=xx
3. Remove device
4. Reinsert device
5. Configure wvdial
6. Connect using wvdial

I am attaching the relevant section of '/var/log/messages' and the output of lsusb.

Please let me know what else is required to debug and fix this.

cheers,
- steve

Comment 1 steve 2009-08-04 06:34:59 UTC
Created attachment 356105 [details]
output of lsusb with device plugged in

Comment 2 Niels Haase 2009-08-05 11:42:55 UTC
Thanks for filling this bug. Can you please do the following?

Please shutdown NM and restart it with this command:

NM_SERIAL_DEBUG=1 /usr/sbin/NetworkManager --no-daemon

Then please try your step 2 from above (rmmod usb_storage && modprobe usbserial vendor=xx product=xx) but leave the device in the system.

Hopefully to see some debug output from NM in addition to the modem device. Please attach this output. Thank you.


-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 3 steve 2009-08-06 05:50:29 UTC
Hello Niels,

Thanks for the quick reply ...

(In reply to comment #2)
> Thanks for filling this bug. Can you please do the following?
> 
> Please shutdown NM and restart it with this command:
> 
> NM_SERIAL_DEBUG=1 /usr/sbin/NetworkManager --no-daemon
> 
> Then please try your step 2 from above (rmmod usb_storage && modprobe usbserial
> vendor=xx product=xx) but leave the device in the system.
> 
> Hopefully to see some debug output from NM in addition to the modem device.
> Please attach this output. Thank you.

I've attached the requested output. I don't know if this would be much help
though. Since there was just that one relevant line about the missing broadband
capabilities in the NM_SERIAL_DEBUG output. The lines preceding that are of nm
connecting to the available wireless network.

I've also attached the relevant output from dmesg, for good measure.

cheers,
- steve

Comment 4 steve 2009-08-06 05:52:16 UTC
Created attachment 356466 [details]
NM_SERIAL_DEBUG=1 /usr/sbin/NetworkManager --no-daemon

Comment 5 steve 2009-08-06 05:55:02 UTC
Created attachment 356467 [details]
dmesg output

Comment 6 Peter Robinson 2009-08-14 14:14:07 UTC
I'm seeing very similar with ZTE HSUPA USB Modem - Model MF636.

I can report it as a separate bug if you'd prefer.

The following udev rules get it to the point I can make it work with wvdial.

ACTION!="add", GOTO="ZTE_End"
#
SUBSYSTEM=="usb", SYSFS{idProduct}=="0033",
SYSFS{idVendor}=="19d2", GOTO="ZTE_Modem"
#
LABEL="ZTE_Modem"
RUN+="/sbin/modprobe usbserial vendor=0x19d2 product=0x0033",
MODE="660", GROUP="dialout"
#
LABEL="ZTE_End"

Hal rules

<!-- ZTE MF636 HSDPA USB dongle 4 -->
  <match key="@info.parent:usb.product_id" int="0x0033">
    <match key="@info.parent:usb.interface.number" int="4">
      <append key="modem.command_sets" type="strlist">GSM-07.07</append>
      <append key="modem.command_sets" type="strlist">GSM-07.05</append>
  </match>
</match>

But sometimes it works on interfave 4 or sometimes interface 2!

I also noticed when you first plug it in its detected as a USB cdrom. If you 'eject /dev/sr0' it will then initiated and come up with the microSD slot.

Comment 7 steve 2009-08-17 06:30:24 UTC
Sadly, the config mentioned in comment #6 does not work for me (of course, i adapted the product/vendor strings for my device).

cheers,
- steve

Comment 8 steve 2009-08-27 15:01:49 UTC
Good news !! ...well, partly good anyways.

My modem finally works with the latest upstream usb_modeswich and wvdial. However, NetworkManager still stubbornly refuses to believe that my card has 'mobile broadband capabilities' ! Could we please fix this so that I don't have to rewrite dns configuration and manage routes manually whenever I want to switch between using NM and wvdial ?

Here is what I did to collect the debug info I am attaching:

a. Did a 'service NetworkManager stop' followed by a
NM_SERIAL_DEBUG=1 /usr/sbin/NetworkManager --no-daemon

b. I inserted the card
c. The card gets recognized as a usb-storage device with id 19d2:fff6
d. modprobe -v usbserial vendor=0x19d2 product=0xfff1 (look at [1] below for extra info)
e. usb_modeswitch (*not* the current Fedora latest, the latest upstream usb_modeswitch ref bug #519332)
f. The card switches mode to a serial device with id 19d2:fff1 and gives me a /dev/ttyUSB0, which I can use with wvdial.

The debug output of NM and the relevant section from /var/log/messages is attached.

Please let me know if you need anything more.

cheers,
- steve

[1] I imagine doing this wouldn't be required when we get the kernel with this patch:
http://patchwork.kernel.org/patch/36704/

I wonder if this affects NM too ?

cheers,
- steve

Comment 9 steve 2009-08-27 15:02:41 UTC
Created attachment 358886 [details]
NM_SERIAL_DEBUG=1 /usr/sbin/NetworkManager --no-daemon

Comment 10 steve 2009-08-27 15:03:09 UTC
Created attachment 358887 [details]
relevant section of /var/log/messages

Comment 11 Peter Robinson 2009-10-02 15:11:28 UTC
*** Bug 526586 has been marked as a duplicate of this bug. ***

Comment 12 Paul Ionescu 2009-10-02 17:29:19 UTC
Hi Peter,

I don't think that bug 526586 is a duplicate of this bug, because my modem
is recognized by ModemManager and NetworkManager as you can see from the
attached logs in that bug report.

I am able to create a new broadband connection with nm-applet and the process
goes pretty far in talking with the modem.

Please see the text from the attachment_id = 363262 to see the detailed
communication between modem-manager and the modem.

Here is the lsusb before usb_modeswitch of my ZTE MF626 usb modem:

Bus 002 Device 007: ID 19d2:2000 ONDA Communication S.p.A. 

and after usb_modeswitch:

Bus 002 Device 008: ID 19d2:0031 ONDA Communication S.p.A.

Comment 13 Dan Williams 2009-10-30 08:18:06 UTC
Give the packages in:

https://admin.fedoraproject.org/updates/F11/FEDORA-2009-10696

a try; they have specific fixes to enable recognition of ZTE devices, and I've tested them myself on a 3UK MF627.

Comment 14 steve 2009-10-30 09:13:40 UTC
Hello Dan,

(In reply to comment #13)
> Give the packages in:
> 
> https://admin.fedoraproject.org/updates/F11/FEDORA-2009-10696
> 
> a try; they have specific fixes to enable recognition of ZTE devices, and I've
> tested them myself on a 3UK MF627.  

I am sorry to report that this version still does not work with my ZTE device. I could post the log messages and the output of NM_SERIAL_DEBUG but it is essentially the same as the previous attachments -- when usb_modeswitch switches the device from storage to modem mode, NM complains:

NetworkManager: <info>  (ttyUSB1): ignoring due to lack of mobile broadband capabilties
NetworkManager: <info>  (ttyUSB0): ignoring due to lack of mobile broadband capabilties
NetworkManager: <info>  (ttyUSB2): ignoring due to lack of mobile broadband capabilties
NetworkManager: <info>  (ttyUSB4): ignoring due to lack of mobile broadband capabilties
NetworkManager: <info>  (ttyUSB3): ignoring due to lack of mobile broadband capabilties

let me know if you need any more info.

cheers,
- steve

Comment 15 steve 2009-10-30 12:15:45 UTC
Hello Dan,

I got a bit curious and had a bit of time so I thought I'd help out with the debugging (although I don't know much about NM internals or working with USB devices and modems ...etc for that matter).

So, i downloaded the sources and poked around. I found 'nm-modem-probe' and tried it out after attaching my device and switching it's mode from storage to modem (using usb_modeswitch as mentioned earlier):

[root@laptop ~]# /lib/udev/nm-modem-probe --vid 0x19D2 --pid 0xFFF1 --verbose --timeout 1 /dev/ttyUSB0 
L: (1256902849.109168) main(): (/dev/ttyUSB0): usb-vid 0x19d2  usb-pid 0xfff1  usb-intf 0  driver '(null)'
L: (1256902849.109280) main(): probing /dev/ttyUSB0
L: (1256902849.109406) modem_probe_caps(): Sending ZTE init string...
': (1256902849.109425) modem_send_command(): Sending: 'ATE0+CPMS?
L: (1256902849.120164) modem_wait_reply(): Got: 'ATE0+CPMS?'
L: (1256902849.122413) modem_wait_reply(): Got: 'ATE0+CPMS?
ERROR
'
L: (1256902849.622590) modem_probe_caps(): Error sending ZTE init string
': (1256902849.622631) modem_send_command(): Sending: 'AT+GCAP
L: (1256902849.632256) modem_wait_reply(): Got: '
+GCAP: +CIS707-A, CIS-856, +MS, +ES, +DS, +FCLASS

OK
'
L: (1256902849.632327) modem_probe_caps(): GCAP response: +GCAP: +CIS707-A, CIS-856, +MS, +ES, +DS, +FCLASS
L: (1256902849.633028) main(): /dev/ttyUSB0: caps (0x17A) CDMA-1x EVDOr0   time: 523ms


Like I said, i don't know much about modems, but I hope this output is useful. However, in the process of my investigation i did find out a couple of things:

a. nm-modem-probe has a subtle although practically not-relevant bug. In the modem_probe_caps(), which the if(vid == ZTE_VENDOR_ID) section the while loop will not be entered unless we specify a non-zero timeout on the commandline. I said not-relevant because i noticed the udev rules file does infact use the timeout option each time it invokes the command.

b. It does seem like the nm-modem-probe even gets called from the udev rules when '/dev/ttyUSB0' appears. I admit I barely understand the entire hal/udev stack but maybe the problem is in the 77-nm-zte-port-types.rules file, which does not seem to have an entry that would correspond to my device:

Bus 005 Device 009: ID 19d2:fff1 ONDA Communication S.p.A.

I am just guessing here.
Anyways, that's about the extent I could go to debugging this for now. However, i am willing to try out stuff if you could give me clear instructions on what needs to be done.

cheers,
- steve

Comment 16 Peter Robinson 2009-10-30 14:44:26 UTC
Doesn't work here on Fedora 12 for a ZTE MF636 with yesterdays rawhide

usb 1-3.4: new high speed USB device using ehci_hcd and address 6
usb 1-3.4: New USB device found, idVendor=19d2, idProduct=0033
usb 1-3.4: New USB device strings: Mfr=3, Product=2, SerialNumber=4
usb 1-3.4: Product: ZTE CDMA Technologies MSM
usb 1-3.4: Manufacturer: ZTE,Incorporated
usb 1-3.4: SerialNumber: 1234567890ABCDEF
usb 1-3.4: configuration #1 chosen from 1 choice
Initializing USB Mass Storage driver...
scsi4 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 6
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 4:0:0:0: CD-ROM            ZTE      USB SCSI CD-ROM  2.31 PQ: 0 ANSI: 2
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.20
sr 4:0:0:0: Attached scsi CD-ROM sr0
sr 4:0:0:0: Attached scsi generic sg1 type 5
ISO 9660 Extensions: Microsoft Joliet Level 1
ISOFS: changing to secondary root
SELinux: initialized (dev sr0, type iso9660), uses genfs_contexts

Comment 17 Dan Williams 2009-11-02 17:42:20 UTC
(In reply to comment #15)
> Hello Dan,
> 
> I got a bit curious and had a bit of time so I thought I'd help out with the
> debugging (although I don't know much about NM internals or working with USB
> devices and modems ...etc for that matter).
> 
> So, i downloaded the sources and poked around. I found 'nm-modem-probe' and
> tried it out after attaching my device and switching it's mode from storage to
> modem (using usb_modeswitch as mentioned earlier):
> 
> [root@laptop ~]# /lib/udev/nm-modem-probe --vid 0x19D2 --pid 0xFFF1 --verbose
> --timeout 1 /dev/ttyUSB0 
> L: (1256902849.109168) main(): (/dev/ttyUSB0): usb-vid 0x19d2  usb-pid 0xfff1 
> usb-intf 0  driver '(null)'
> L: (1256902849.109280) main(): probing /dev/ttyUSB0
> L: (1256902849.109406) modem_probe_caps(): Sending ZTE init string...
> ': (1256902849.109425) modem_send_command(): Sending: 'ATE0+CPMS?
> L: (1256902849.120164) modem_wait_reply(): Got: 'ATE0+CPMS?'
> L: (1256902849.122413) modem_wait_reply(): Got: 'ATE0+CPMS?
> ERROR
> '
> L: (1256902849.622590) modem_probe_caps(): Error sending ZTE init string
> ': (1256902849.622631) modem_send_command(): Sending: 'AT+GCAP
> L: (1256902849.632256) modem_wait_reply(): Got: '
> +GCAP: +CIS707-A, CIS-856, +MS, +ES, +DS, +FCLASS
> 
> OK
> '
> L: (1256902849.632327) modem_probe_caps(): GCAP response: +GCAP: +CIS707-A,
> CIS-856, +MS, +ES, +DS, +FCLASS
> L: (1256902849.633028) main(): /dev/ttyUSB0: caps (0x17A) CDMA-1x EVDOr0  
> time: 523ms
> 
> 
> Like I said, i don't know much about modems, but I hope this output is useful.
> However, in the process of my investigation i did find out a couple of things:
> 
> a. nm-modem-probe has a subtle although practically not-relevant bug. In the
> modem_probe_caps(), which the if(vid == ZTE_VENDOR_ID) section the while loop
> will not be entered unless we specify a non-zero timeout on the commandline. I
> said not-relevant because i noticed the udev rules file does infact use the
> timeout option each time it invokes the command.
> 
> b. It does seem like the nm-modem-probe even gets called from the udev rules
> when '/dev/ttyUSB0' appears. I admit I barely understand the entire hal/udev
> stack but maybe the problem is in the 77-nm-zte-port-types.rules file, which
> does not seem to have an entry that would correspond to my device:
> 
> Bus 005 Device 009: ID 19d2:fff1 ONDA Communication S.p.A.
> 
> I am just guessing here.
> Anyways, that's about the extent I could go to debugging this for now. However,
> i am willing to try out stuff if you could give me clear instructions on what
> needs to be done.
> 

Steve, your device is an EVDO/CDMA device that shouldn't need half the hacks that the GSM/UMTS ones do.  What's the specific model number of yours?

Comment 18 Dan Williams 2009-11-02 17:43:32 UTC
Peter: have you ejected the fake CD-ROM drive with usb_modeswitch or some other udev rules?  Many modems show up as fake CDs (whcih contain the windows drivers) and they aren't usable as modems until they've been ejected.  There's a package called usb_modeswitch that can do this for you.

Comment 19 Peter Robinson 2009-11-02 19:12:56 UTC
(In reply to comment #18)
> Peter: have you ejected the fake CD-ROM drive with usb_modeswitch or some other
> udev rules?  Many modems show up as fake CDs (whcih contain the windows
> drivers) and they aren't usable as modems until they've been ejected.  There's
> a package called usb_modeswitch that can do this for you.  

Nope, I hadn't. I didn't realise you needed to as I assumed udev (or something) did that automatically like the huawei ones do. Its in the office so I'll try to get a chance to try that tomorrow.

Comment 20 Dan Williams 2009-11-02 20:46:12 UTC
Peter, Huawei eject id done in the kernel drivers, while ZTE eject is not.  The fake driver CD ejection is really "policy", and policy decisions are usually not done in the kernel but by userspace like udev.  People just started using the ZTE devices later and thus they weren't able to be included in the kernel for ejecting.

Comment 21 steve 2009-11-04 06:27:54 UTC
Hello Dan,

Thanks for the reply.

(In reply to comment #17)
> 
> Steve, your device is an EVDO/CDMA device that shouldn't need half the hacks
> that the GSM/UMTS ones do.  What's the specific model number of yours?  

The exact model number is ZTE AC8710. Although, the lsusb lists it as:

Bus 005 Device 003: ID 19d2:fff1 ONDA Communication S.p.A.

...after executing usb_modeswitch, that is. Prior to executing the command the only difference is the PCI id (which is 19d2:fff6).

Also, I understand the comment you made to Paul about policy, but was wondering whether this event (ie: ejecting the fake CD device or calling usb_modeswitch) can be included as a udev rule or a NM backend 'callout', since currently(*) at least these devices only make sense as a modem and not as storage.

cheers,
- steve

(*) Although interesting work is being done to reflash the device so that a bootable live cd image can be put on the storage (which at least in my device, holds the winduhs driver and dialer for the device). This would allow for a bootable and internet ready liveUSB device ! :)

Comment 22 Dan Williams 2009-11-15 18:35:10 UTC
The right place for all the modem-mode switch stuff is usb_modeswitch.  Upstream is working on making that more automatic for distro users since it currently is not (as you've found).  NM takes over after the modeswitch is done and the device is in modem mode.

Comment 23 steve 2009-11-16 02:28:39 UTC
Hello Dan,

(In reply to comment #22)
> The right place for all the modem-mode switch stuff is usb_modeswitch. 
> Upstream is working on making that more automatic for distro users since it
> currently is not (as you've found).  NM takes over after the modeswitch is done
> and the device is in modem mode.  

I agree with the bit about usb_modeswtich being responsible for the switching and I have no issues running it manually until the time that it gets automated.

However, the issue in this bug is that after usb_modeswitch, NM does not take over ie: it does not recognize the device as having "mobile broadband
capabilities" and so I'm forced to use wvdial.

cheers,
- steve

Comment 24 Dan Williams 2009-11-16 06:55:02 UTC
(In reply to comment #23)
> Hello Dan,
> 
> (In reply to comment #22)
> > The right place for all the modem-mode switch stuff is usb_modeswitch. 
> > Upstream is working on making that more automatic for distro users since it
> > currently is not (as you've found).  NM takes over after the modeswitch is done
> > and the device is in modem mode.  
> 
> I agree with the bit about usb_modeswtich being responsible for the switching
> and I have no issues running it manually until the time that it gets automated.
> 
> However, the issue in this bug is that after usb_modeswitch, NM does not take
> over ie: it does not recognize the device as having "mobile broadband
> capabilities" and so I'm forced to use wvdial.

So in the case, lets do some investigation.  I assume you already have https://admin.fedoraproject.org/updates/F11/FEDORA-2009-10696 installed and usb_modeswitch is set up.

Edit /lib/udev/rules.d/77-nm-probe-modem-capabilities.rules and change this line:

SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="?*", IMPORT{program}="nm-modem-probe --vid 0x$attr{idVendor} --pid 0x$attr{idProduct} --usb-interface $env{NM_MODEM_USB_INTERFACE_NUMBER} --driver $env{NM_MODEM_DRIVER} --delay 5000 --timeout 8000 --export $tempnode", GOTO="nm_modem_probe_end"

to:

SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="?*", IMPORT{program}="nm-modem-probe --vid 0x$attr{idVendor} --pid 0x$attr{idProduct} --usb-interface $env{NM_MODEM_USB_INTERFACE_NUMBER} --driver $env{NM_MODEM_DRIVER} --delay 5000 --timeout 8000 --export --log /tmp/probe.log --verbose $tempnode", GOTO="nm_modem_probe_end"

(ie, add the "--log /tmp/probe.log --verbose" right before the $tempnode)

Then plug your device in, wait about 30 seconds (until NM fails to recognize the device at least) and attach /tmp/probe.log to this bug report.  Thanks!

Comment 25 kymap4ever 2009-11-18 17:50:01 UTC
hello

i was switch my zte mf636 always still on modem mode:
# lsusb
Bus 002 Device 013: ID 19d2:0031 ONDA Communication S.p.A.
.
and this work good on fedora11 and ubuntu but NetworkManager on fedora12 x86-64 does not recognize the device.
could ask someone here how to configure 77-mm-zte-port-types.rules to do it work? or do some another changes?

thnx

Comment 26 Dan Williams 2009-11-18 20:57:55 UTC
(In reply to comment #25)
> hello
> 
> i was switch my zte mf636 always still on modem mode:
> # lsusb
> Bus 002 Device 013: ID 19d2:0031 ONDA Communication S.p.A.
> .
> and this work good on fedora11 and ubuntu but NetworkManager on fedora12 x86-64
> does not recognize the device.
> could ask someone here how to configure 77-mm-zte-port-types.rules to do it
> work? or do some another changes?

Could you file a new bug with this information, and then:

1) unplug your device
2) service NetworkManager stop
3) killall -TERM modem-manager
4) modem-manager --debug
5) plug the device in

and the in that new bug, paste the modem-manager output into the bug?

Comment 27 kymap4ever 2009-11-22 15:43:21 UTC
(In reply to comment #6)
> I'm seeing very similar with ZTE HSUPA USB Modem - Model MF636.
> 
> I can report it as a separate bug if you'd prefer.
> 
> The following udev rules get it to the point I can make it work with wvdial.
> 
> ACTION!="add", GOTO="ZTE_End"
> #
> SUBSYSTEM=="usb", SYSFS{idProduct}=="0033",
> SYSFS{idVendor}=="19d2", GOTO="ZTE_Modem"
> #
> LABEL="ZTE_Modem"
> RUN+="/sbin/modprobe usbserial vendor=0x19d2 product=0x0033",
> MODE="660", GROUP="dialout"
> #
> LABEL="ZTE_End"
> 
> Hal rules
> 
> <!-- ZTE MF636 HSDPA USB dongle 4 -->
>   <match key="@info.parent:usb.product_id" int="0x0033">
>     <match key="@info.parent:usb.interface.number" int="4">
>       <append key="modem.command_sets" type="strlist">GSM-07.07</append>
>       <append key="modem.command_sets" type="strlist">GSM-07.05</append>
>   </match>
> </match>
> 
> But sometimes it works on interfave 4 or sometimes interface 2!
> 
> I also noticed when you first plug it in its detected as a USB cdrom. If you
> 'eject /dev/sr0' it will then initiated and come up with the microSD slot.  

i get a ppp connection with wvdial, but firefox does not let me surf the web.
Any idea why?(firefox is in online mode)

Comment 28 Dan Williams 2009-11-23 05:19:43 UTC
(In reply to comment #27)
> (In reply to comment #6)
> > I'm seeing very similar with ZTE HSUPA USB Modem - Model MF636.
> > 
> > I can report it as a separate bug if you'd prefer.
> > 
> > The following udev rules get it to the point I can make it work with wvdial.
> > 
> > ACTION!="add", GOTO="ZTE_End"
> > #
> > SUBSYSTEM=="usb", SYSFS{idProduct}=="0033",
> > SYSFS{idVendor}=="19d2", GOTO="ZTE_Modem"
> > #
> > LABEL="ZTE_Modem"
> > RUN+="/sbin/modprobe usbserial vendor=0x19d2 product=0x0033",
> > MODE="660", GROUP="dialout"
> > #
> > LABEL="ZTE_End"
> > 
> > Hal rules
> > 
> > <!-- ZTE MF636 HSDPA USB dongle 4 -->
> >   <match key="@info.parent:usb.product_id" int="0x0033">
> >     <match key="@info.parent:usb.interface.number" int="4">
> >       <append key="modem.command_sets" type="strlist">GSM-07.07</append>
> >       <append key="modem.command_sets" type="strlist">GSM-07.05</append>
> >   </match>
> > </match>
> > 
> > But sometimes it works on interfave 4 or sometimes interface 2!
> > 
> > I also noticed when you first plug it in its detected as a USB cdrom. If you
> > 'eject /dev/sr0' it will then initiated and come up with the microSD slot.  
> 
> i get a ppp connection with wvdial, but firefox does not let me surf the web.
> Any idea why?(firefox is in online mode)  

Because Firefox listens to NetworkManager for connected/disconnected events, and since the connection is using wvdial and not NetworkManager, nothing knows that you're online.  The solution to this problem is to figure out why modem-manager can't detect your device, which I gave debugging information for in comment #26 and a request to file a new bug for that problem (since this problem is specific to Fedora 11).

Comment 29 steve 2009-12-11 22:29:14 UTC
Hello Dan,

I am sorry for it took so long for me to come back on this. Furthermore, I've updated to F12 now and do not have a F11 box to track this any more.

The good news is my modem works with NM on F12, the bad news is, it is a very specific definition of 'works' :).

So, as far as this bug is concerned, i am ok with you closing this (since I seem to be the only reporter with this /specific/ issue with the ZTE AC8710 card) and I could file a new bug for F12.

Or I could just update the 'version' of this BZ and we could just continue debugging the F12 issues here.

In brief, after i switch the mode using usb_modeswitch in F12, NetworkManager has to be restarted (sometimes a couple of times) before it can recognize the device. 

Additionally, if I use wvdial instead of restarting NM, after I kill wvdial, NM is capable of immediately using the device without the need for a restart.

Let me know if you want a new BZ and the additional information you would need.

- steve

Comment 30 Dan Williams 2009-12-11 23:36:46 UTC
Ok, lets debug a little more.  After the modem is connected with wvdial, run the following command as root:

stty -a -F /dev/ttyUSB0

of course use the TTY that you gave to wvdial if it's not USB0.  Thanks!

Comment 31 steve 2009-12-12 11:24:00 UTC
Hi Dan,

Thanks for the immediate reply !

(In reply to comment #30)
> Ok, lets debug a little more.  After the modem is connected with wvdial, run
> the following command as root:
> 
> stty -a -F /dev/ttyUSB0
> 
> of course use the TTY that you gave to wvdial if it's not USB0.  Thanks!  

-----------------------------------------------------------
[root@localhost ~]# stty -a -F /dev/ttyUSB0
speed 9600 baud; rows 0; columns 0; line = 3;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^A; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke
[root@localhost ~]# 
-----------------------------------------------------------

I am also attaching the contents of the /var/log/messages file which contains some comments in lines with the marker '-----------', collected while I did this:
- called usb_modeswitch
- waited for NM to give up on the device (the exact message is in the file)
- ran wvdial
- collected the stty output above
- killed wvdial
- waited ...nothing happened so restarted NM
- NM immediately saw the device so I connected using NM

Let me know if you need anything else.

cheers,
- steve
 Note that this time, NM did not immediately reco

Comment 32 steve 2009-12-12 11:25:18 UTC
Created attachment 377858 [details]
/var/log/message reffered to in Comment #31

Comment 33 Dan Williams 2009-12-14 22:55:03 UTC
Hmm, just to confirm, you did the 'stty' after wvdial established a successful connection, right?  I was operating under the theory that clocal/crtscts were the magic settings but I guess that's not the case here.

Comment 34 steve 2009-12-17 14:39:42 UTC
(In reply to comment #33)
> Hmm, just to confirm, you did the 'stty' after wvdial established a successful
> connection, right?  I was operating under the theory that clocal/crtscts were
> the magic settings but I guess that's not the case here.  

Yes. stty output was collected after wvdial established a successful connection. 

FWIW, i captured stty both before and after a successful connection but the diff is empty :/.

Is there a NM or modem-manager way to debug what is happening (for instance, would a strace of wvdial & NM help ?)

Anyways, here is some more new info. If I wait long enough for modem-manager to close all recognized USB ports (ie: see the attached file, again events delimited by a '--------') and then restart NM, it immediately recognizes the device.

I really want this to work with NM flawlessly, especially since it now works after a bit of a delay, now.

cheers,
- steve

Comment 35 steve 2009-12-17 14:41:29 UTC
Created attachment 379010 [details]
No wvdial needed if I wait for 3 mins. before restarting NM (Comment #33)

Comment 36 Dan Williams 2009-12-23 18:25:29 UTC
I'm going to move this bug to F12 since that is what steve is currently using.

There aren't any known ZTE *GSM* issues in NM 0.7.x in Fedora 11 at this time.

Comment 37 Dan Williams 2010-01-02 05:23:35 UTC
Steve, can you try the ModemManager packages here?

http://koji.fedoraproject.org/koji/buildinfo?buildID=149089

They fix a specific issue with unresponsive serial ports that could be blocking ModemManager in your case.

Comment 38 Bug Zapper 2010-11-04 10:36:52 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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 39 Bug Zapper 2010-12-05 06:39:23 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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.