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
Created attachment 356105 [details] output of lsusb with device plugged in
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
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
Created attachment 356466 [details] NM_SERIAL_DEBUG=1 /usr/sbin/NetworkManager --no-daemon
Created attachment 356467 [details] dmesg output
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.
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
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
Created attachment 358886 [details] NM_SERIAL_DEBUG=1 /usr/sbin/NetworkManager --no-daemon
Created attachment 358887 [details] relevant section of /var/log/messages
*** Bug 526586 has been marked as a duplicate of this bug. ***
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.
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.
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
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
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
(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?
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.
(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.
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.
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 ! :)
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.
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
(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!
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
(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?
(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)
(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).
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
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!
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
Created attachment 377858 [details] /var/log/message reffered to in Comment #31
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.
(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
Created attachment 379010 [details] No wvdial needed if I wait for 3 mins. before restarting NM (Comment #33)
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.
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.
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
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.