GNOME Bugzilla – Bug 604369
ZTE MF628 HSDPA USB modem not always recognized by network-manager 0.8
Last modified: 2010-01-18 20:51:27 UTC
Distribution: Ubuntu 9.10 Karmic, ModemManager Version: 0.2.git.20091208t060758.07114d4-0ubuntu1~nmt1~karmic The usb-device sometimes works when I plug it in before startup or when I kill modem-manager when i already have plugged it in. When plugged in on a running system I have to eject the zero-CD mount (which isn't a big issue), to switch it to modem-mode. lsusb (zero-CD mode) ID 19d2:2000 ONDA Communication S.p.A. lsusb (modem mode): ID 19d2:0015 ONDA Communication S.p.A. With umtsmon the device works well, i can also "repair" the state of the device with running umtsmon. If the modem-manger has failed and I then connect with umtsmon and then run modem-manger again it suddenly works. There is also this related bug report: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/269858
Created attachment 149588 [details] ZTE_MF828_successful.log
Created attachment 149589 [details] ZTE_MF628_failed.log
Created attachment 149591 [details] umtsmon -v 6 &> umtsmon.log I actually wonder what's different about "umtsmon", and why it can successfully initialize such devices. I have attached the umtsmon stdout/stderr output. No idea whether that helps. Just allow me a bit of nagging about modem-manager and NM :-) I think this system is excellent when it works, but it's very hard to find out the reasons when it doesn't (which is a general problem with Linux and Hardware). For instance it took very long to find out that modem-manager actually did recognize my MF628 as a modem (but it didn't succeed in querying it). Or that for my Huawai E1552 I have to set the "Network" parameter to make it work (the other bug). Perhaps there could be some kind of "diagnostics" dbus interfaces for such daemons, with an extra GUI client to monitor things. In case NM or MM fails, it would be cool to see a "view log" button somewhere (which pops up this diagnostics GUI. I guess the diagnostics information should be somehow organized on an "action" basis. For instance: * MM detects a new modem device --> Query failed --> Log of the communication with the modem. * Or... user tries to connect to a certain network --> Failed --> Log of this particular action. As I'm a developer, I wouldn't mind working on this... Regards, Norbert
Whats the contents of your /lib/udev/rules.d/61-option-modem-modeswitch.rules file?
Created attachment 149633 [details] 61-option-modem-modeswitch.rules
Hmm... Adding the line ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="2000", RUN+="modem-modeswitch -v 0x%s{idVendor} -p 0x%s{idProduct} -t option-zerocd" to 61-option-modem-modeswitch.rules switches the MF628 from zero-CD to modem-mode instantly. Which is cool. But that doesn't solve the problem that ModemManager doesn't really like that device. When running, ModemManager now doesn't recognize the device at all, and when I kill it, it still has this "Got failure code 100: Unknown error" problem... (see the ZTE_MF628_failed.log above) Dec 13 17:36:26 daisy NetworkManager: <info> modem manager disappeared Dec 13 17:36:26 daisy NetworkManager: <info> Trying to start the modem-manager... Dec 13 17:36:26 daisy NetworkManager: <info> modem-manager is now available Dec 13 17:36:26 daisy modem-manager: Loaded plugin Nokia Dec 13 17:36:26 daisy modem-manager: Loaded plugin Gobi Dec 13 17:36:26 daisy modem-manager: Loaded plugin Generic Dec 13 17:36:26 daisy modem-manager: Loaded plugin Sierra Dec 13 17:36:26 daisy modem-manager: Loaded plugin Novatel Dec 13 17:36:26 daisy modem-manager: Loaded plugin Option High-Speed Dec 13 17:36:26 daisy modem-manager: Loaded plugin Ericsson MBM Dec 13 17:36:26 daisy modem-manager: Loaded plugin Option Dec 13 17:36:26 daisy modem-manager: Loaded plugin ZTE Dec 13 17:36:26 daisy modem-manager: Loaded plugin Huawei Dec 13 17:36:26 daisy modem-manager: Loaded plugin MotoC Dec 13 17:36:26 daisy modem-manager: (ttyUSB0) opening serial device... Dec 13 17:36:26 daisy modem-manager: (ttyUSB0): probe requested by plugin 'ZTE' Dec 13 17:36:26 daisy modem-manager: (ttyUSB1) opening serial device... Dec 13 17:36:26 daisy modem-manager: (ttyUSB1): probe requested by plugin 'ZTE' Dec 13 17:36:26 daisy modem-manager: (ttyUSB2) opening serial device... Dec 13 17:36:26 daisy modem-manager: (ttyUSB2): probe requested by plugin 'ZTE' Dec 13 17:36:27 daisy modem-manager: Got failure code 100: Unknown error Dec 13 17:36:28 daisy modem-manager: Got failure code 100: Unknown error Dec 13 17:36:29 daisy modem-manager: Got failure code 100: Unknown error Dec 13 17:36:30 daisy modem-manager: Got failure code 100: Unknown error Dec 13 17:36:31 daisy modem-manager: Got failure code 100: Unknown error Dec 13 17:36:32 daisy modem-manager: Got failure code 100: Unknown error Dec 13 17:36:33 daisy modem-manager: Got failure code 100: Unknown error Dec 13 17:36:33 daisy modem-manager: Got failure code 100: Unknown error Dec 13 17:36:33 daisy modem-manager: (ttyUSB0) closing serial device... Dec 13 17:36:33 daisy modem-manager: (ttyUSB2) closing serial device... Dec 13 17:36:40 daisy modem-manager: (ttyUSB1) closing serial device...
I tried to investigate the "Got failure code 100: Unknown error" with minicom a bit. I think this modem doesn't accept commands like "AT+GCAP", before the pin has been sent. But MM seems to send "AT+GCAP" as the first command when detecting a modem. Also, a lot of things mentioned in this thread seem to apply: http://ubuntuforums.org/showthread.php?p=7539275 For instance that the ttyUSBx are sometimes 1-3 rather than 0-2. Or that "+ZUSIMR:2" is being reported by the modem every second. Welcome to minicom 2.3 OPTIONS: I18n Compiled on Sep 25 2009, 23:45:34. Port /dev/ttyUSB1 Press CTRL-A Z for help on special keys AT+GCAP ERROR AT OK AT+CPIN? +CPIN: SIM PIN OK AT+CPIN="1234" OK +ZDONR: "Not Found" +ZPASR: "No Service" +ZDONR: "one",232,5,"CS_ONLY","ROAM_OFF" +ZPASR: "UMTS" +ZDONR: "",,,"CS_ONLY","ROAM_OFF" +ZPASR: "UMTS" +ZDONR: "",,,"CS_PS","ROAM_OFF" +ZPASR: "UMTS" +ZUSIMR:2 +ZDONR: "yesss!",232,5,"CS_PS","ROAM_OFF" +ZUSIMR:2 +ZUSIMR:2 +ZUSIMR:2 (reported for a couple of minutes) .... AT+GCAP (now it works) +GCAP: +CGSM,+DS,+ES OK
Created attachment 149663 [details] [review] Terrible hack - just to make it work This patch makes it work, but of course it's just a hack. But it should demonstrate where the problems are: The modem only responds to AT AT&F AT+CGMM --> reports "MF628" AT+CPIN? ...before it has been unlocked with (AT+CPIN=xxxx) not even the echoing can be turned off before that (ATE0). Dan, any suggestions how this could be done in a proper way (perhaps having a separate plugin for the MF628)?
(In reply to comment #6) > Hmm... > > Adding the line > > ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="2000", RUN+="modem-modeswitch -v > 0x%s{idVendor} -p 0x%s{idProduct} -t option-zerocd" > > to 61-option-modem-modeswitch.rules Don't do that; it's known to cause problems with these devices because modem-modeswitch's 'option-zerocd' method is /only/ for Option devices. Use usb_modeswitch to get the correct switching method for ZTE devices please. The problem here is that ModemManager isn't correctly handling PIN requests during probing; at this point we don't know the device's capabilities and thus we don't know whether it's a CDMA or GSM device. There may be a few ways to handle this by checking the model string like you mention, since we know the capabilities of certain models. This particular area needs more thought if the modem doesn't at least return capability information. Before you've entered the pin, can you try at+gmi at+gmr ati1 ati2 ati3 ati4 ati5 ati6 ati7 ati8 ati9 at&v at+clac Thanks!
(In reply to comment #9) > (In reply to comment #6) > > Hmm... > > > > Adding the line > > > > ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="2000", RUN+="modem-modeswitch -v > > 0x%s{idVendor} -p 0x%s{idProduct} -t option-zerocd" > > > > to 61-option-modem-modeswitch.rules > > Don't do that; it's known to cause problems with these devices because > modem-modeswitch's 'option-zerocd' method is /only/ for Option devices. Use > usb_modeswitch to get the correct switching method for ZTE devices please. Hmm - works quite well - and the kernel treats it as an "option" device. Or is that a consequence of the additional line in 61-option-modem-modeswitch.rules kernel: [ 982.824854] option 4-3:1.1: GSM modem (1-port) converter detected kernel: [ 982.824958] usb 4-3: GSM modem (1-port) converter now attached to ttyUSB1 kernel: [ 982.826596] option 4-3:1.2: GSM modem (1-port) converter detected kernel: [ 982.826692] usb 4-3: GSM modem (1-port) converter now attached to ttyUSB2 kernel: [ 982.829565] option 4-3:1.3: GSM modem (1-port) converter detected kernel: [ 982.829665] usb 4-3: GSM modem (1-port) converter now attached to ttyUSB3 ... modem-manager: (ZTE): GSM modem /sys/devices/pci0000:00/0000:00:04.0/usb4/4-3 claimed port ttyUSB1 ... NetworkManager: <info> (ttyUSB1): new GSM device (driver: 'option1') lsmod | grep option option 28324 1 usbserial 43216 3 option > > The problem here is that ModemManager isn't correctly handling PIN requests > during probing; at this point we don't know the device's capabilities and thus > we don't know whether it's a CDMA or GSM device. There may be a few ways to > handle this by checking the model string like you mention, since we know the > capabilities of certain models. This particular area needs more thought if the > modem doesn't at least return capability information. Yeah - that's probably why umtsmon works - it just "probes" with a plain "AT" - then sends the PIN and then does further probing. > > Before you've entered the pin, can you try > Sure! AT+GMI ERROR AT+GMR BD_YESP671M5V1.0.0B01 BD_YESP671M5V1.0.0B01 1 [Jun 3 2008 16:00:00] OK ATI1 ERROR ATI2 ERROR ATI3 ERROR ATI4 ERROR ATI5 ERROR ATI6 ERROR ATI7 ERROR ATI8 ERROR ATI9 ERROR AT&V ERROR AT+CLAC ERROR *********************************************************** But after AT+CPIN=<PIN> ... AT+GMI ZTE INCORPORATED OK AT+GMR BD_YESP671M5V1.0.0B01 BD_YESP671M5V1.0.0B01 1 [Jun 3 2008 16:00:00] OK ATI1 Manufacturer: ZTE INCORPORATED Model: MF628 Revision: BD_YESP671M5V1.0.0B01 BD_YESP671M5V1.0.0B01 1 [Jun 3 2008 16:00:00] IMEI: 352449021236297 +GCAP: +CGSM,+DS,+ES OK (ATI2..9 report the same) AT&V &C: 2; &D: 2; &F: 0; E: 1; L: 0; M: 0; Q: 0; V: 1; X: 0; Z: 0; S0: 0; S3: 13; S4: 10; S5: 8; S6: 2; S7: 50; S8: 2; S9: 6; S10: 14; S11: 95; S30: 60; +FCLASS: 0; +ICF: 3,3; +IFC: 2,2; +IPR: 115200; +DR: 0; +DS: 0,0,2048,6; +WS46: 12; +CBST: 0,0,1; +CRLP: (61,61,48,6,0),(61,61,48,6,1),(240,240,52,6,2); +CV120: 1,1,1,0,0,0; +CHSN: 0,0,0,0; +CSSN: 0,0; +CREG: 0; +CGREG: 0; +CFUN:; +CSCS: "IRA"; +CSTA: 129; +CR: 0; +CRC: 0; +CMEE: 0; +CGDCONT: (1,"IP",) ; +CGDSCONT: ; +CGTFT: ; +CGEQREQ: ; +CGEQMIN: ; +CGQREQ: ; +CGQMIN: ; +CGEREP: 0,0; +CGDATA: "PPP"; +CGCLASS: "A"; +CGSMS: 3; +CSMS: 0; +CMGF: 0; +CSCA: "",; +CSMP: ,,0,0; +CSDH: 0; +CSCB: 0,"",""; +FDD: 0; +FAR: 0; +FCL: 0; +FIT: 0,0; +ES: ,,; +ESA: 0,,,,0,0,255,; +CMOD: 0; +CVHU: 1; +CPIN: ,; +CMEC: 0,0,0; +CKPD: 1,1; +CGATT: 1; +CGACT: 0; +CPBS: "SM"; +CPMS: "SM","SM","ME"; +CNMI: 3,1,0,0,0; +CMMS: 0; +FTS: 0; +FRS: 0; +FTH: 3; +FRH: 3; +FTM: 96; +FRM: 96; +CCUG: 0,0,0; +COPS: 0,0,""; +CUSD: 0; +CAOC: 1; +CCWA: 1; +CPOL: 0,2,"",0,0,0; +CPLS: 0; +CTZR: 0; +CLIP: 1; +COLP: 0; +CLIR: 0; +ZSNT: 0,0,0; +ZOPRT: 0; +ZCIN: "",,; +ZSNT: 0,0,0; +CLVL: 3; +CMUT: 0; +CMVL: 0 OK AT+CLAC ERROR Hmm... I really wonder whether ModemManager should A) store the debug trace of probing a modem somewhere. B) store the debug trace of the last attempted connect. C) have a diagnostics UI to retrieve those traces. I guess there will always be modem models or eccentric provider settings which cause problems, and at the moment it's very hard - even for skilled computer users - to obtain the necessary information to file bug reports. Regards, Norbert
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #6) > > > Hmm... > > > > > > Adding the line > > > > > > ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="2000", RUN+="modem-modeswitch -v > > > 0x%s{idVendor} -p 0x%s{idProduct} -t option-zerocd" > > > > > > to 61-option-modem-modeswitch.rules > > > > Don't do that; it's known to cause problems with these devices because > > modem-modeswitch's 'option-zerocd' method is /only/ for Option devices. Use > > usb_modeswitch to get the correct switching method for ZTE devices please. > > Hmm - works quite well - and the kernel treats it as an "option" device. Or is > that a consequence of the additional line in 61-option-modem-modeswitch.rules Just because it's driven by the 'option' driver doesn't mean that it's an option device; the option driver is somewhat mis-named and drives a whole bunch of mobile broadband devices from different vendors. It also has nothing to do with modeswitching. I was asked specifically by ZTE engineers, and I myself have experienced problems with using modem-modeswitch that way. ZTE devices use a completely different mode switching method than the actual Option devices do and the two should not be mixed even if it appears to work. It certainly does cause problems. I guess we can try whitelisting various ZTE GMR responses just to at least detect the modem; this will need more work...
Oh BTW, I tried to set a PIN on my ZTE MF627 to test this issue out and it kept returning "operation not supported" or such. Quite odd.
Just for future reference, my MF627's response is: Vendor: ZTE INCORPORATED Model: MF627 Version: BD_3GHAP673A4V1.0.0B02 In any case, I think we can treat any modem that responds to CPIN? as a GSM modem since none of the CDMA devices I have respond to CPIN, and CPIN isn't part of the CDMA IS707 AT command specifications. So this will be easier than I thought.
I was able to set a PIN under windows so at least now I can test this.
Created attachment 149947 [details] ZTE_MF626_minicom_and_syslog.log Just for the record. I bought a ZTE MF 626 today, to see if it's different to the MF 628. The major difference during probing seems to be that it does respond to ATI before sending the PIN (while the MF 628 doesn't).
Check out the probe-cpin branch in git. If that works for you, we can merge it right after the MM 0.3 release...
Well - the probing now works on this modem, but "ATE0 V1" when trying to connect will still fail. I had to send the PIN manually to be able to connect... miface = dbus.Interface(proxy, 'org.freedesktop.ModemManager.Modem.Gsm.Card') miface.SendPin("xxxx")
Yeah, the PIN thing will get fixed by your patch in https://bugzilla.gnome.org/show_bug.cgi?id=604551 and the associated nm-applet logic to send the PIN right after the card is found.
We can resolve this one fixed though and follow up on the PIN stuff in the other bug.