On Thu, 2009-07-02 at 11:33 -0400, Dan Williams wrote: > On Thu, 2009-07-02 at 15:59 +0100, Rick Jones wrote: > > > > --On Thursday, July 02, 2009 10:19:24 -0400 Dan Williams > > <[email protected]> wrote: > > > > > > > > To start with there is always +ZUSIMR:2 every 2 secs., this > > can be > > > > > > stopped by giving any version of AT+CPMS on either port (stops > > the > > > > > > messages on both ports). The only other UMs I see are +ZDONR > > and > > > > > > +ZPASR. > > > > > > > > > > Ugh. That sucks. That means hardcoding stuff on a per-modem > > basis, > > > > > potentially using AT+CGMM responses instead of USB IDs, because > > some > > > > > vendors (Huawei) use the same USB ID for vastly different > > devices to > > > > > work around stupid Windows bugs. > > > > > > > > I've found some ZTE windows inf drivers that appear to confirm > > that > > > > we'll need to hardcode ports. Teh suck. > > > > > > Rick, could I ask you to run 'lsusb -vv' for me while the modem is > > > plugged in *and* has been put into modem mode? > > > > I agree, sucks big-time. And from contributions to forums I've come > > across there are other versions of this device with the same IDs but > > with the modem on a different IF number (Australian version I > > think) :( > > Hmm, the ZTE windows .inf files seem to hardcode it on a USB VID/PID > basis, so I hope we don't run into that. > > > Is there no way to use HAL to define either the valid or the invalid > > interface? With NM 0.7.0 it was necessary to add a .fdi which > > specified the interface, but it doesn't seem to need that any more. Or > > are you trying to get away from HAL? > > Yes, HAL is dead, and already on the 'master' git branch only udev is > used. > > > Output from lsusb attached. It's the same regardless of whether the > > modem is connected or not. One thing I noticed is that the transfer > > type for one of the input EPs in IF3 is Interrupt - that's the only > > one, all the others are Bulk. > > Yeah, that could be a good clue. We'd need to verify that for a few > other ZTE devices though before running with it.
FWIW I've attempted to handle this issue in the following commits to NM: 7406e3a0e8147e23ad3c5b775b3ce940c93ada2a and ModemManager: 52da9990eef279bbc349685a7558d26cf4b7893b 869c69e223208564302ba3be074dafbdf1b02cc2 and ZTE is now on my hate-list. Option did this nicely by implementing a firmware call that returns the port type, which is really the right thing to do. But it boggles my mind that *every ZTE device is different* according to the .INF files. What a maintenance nightmare. Dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
