On Fri, 8 Mar 2002 10:20, Leif Jensen wrote: > On Wed, 6 Mar 2002, Brad Hards wrote: > > On Wed, 6 Mar 2002 08:30, Leif Jensen wrote: > > > T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 > > > D: Ver= 1.10 Cls=02(comm.) Sub=02 Prot=00 MxPS= 8 #Cfgs= 1 > > > > This is an illegal configuration from the Communication Device Class > > spec, Table 20. Sub has to be 00. > > I was going by a list at the linux-usb site, but it must have contained > the table 15-17 info, which I now presume applies only to the I: line. > Is the spec on line? Yes. http://www.usb.org/developers/docs.html http://www.usb.org/developers/data/usb_20.zip is the main USB spec, and http://www.usb.org/developers/data/devclass/usbcdc11.pdf is the Communication Device Class spec. The USB spec is big.
<snip> > I knew this couldn't be a proper way to operate the modem. It does at > least allow AT commands and responses to be exchanged. This may be the > underlying reason I could not exchange data on incoming calls before, > since now the acm driver can do that (yay!). How can I find out what > the E: lines mean? They are endpoint information. Look at the specs, and in the Documentation/usb directory in your linux source directory for a file called proc_usb_info.txt <snip> > Since then I've been able to get a working incoming data connection > up at 14.4Kbps. The fact that this basically works but I have no luck > making outgoing calls is very frustrating. Out is the direction I want. > The incoming connection cannot be escaped by +++ as usual. Is the > escape sequence not going over the right usb interface? Should be transparent. <snip> > The two possibilites I see are > > 1) Data dialing is a premium service I'm not subscribed to. Seems unlikely, unless your phone is locked in some way. > 2) Additional communication needed to enable dialing from data connection. Probably. > On the other hand there are no doubt many undocumented AT or other commands > and no way to discover them. Maybe you could try the "tridge" approach. Set up a program to exhaustively seach the AT space, recording which ones errored. Build up a tree of options, then try to visually assess it. > The other important issue is that the responses from the phone are often > garbled or accompanied by hundreds to thousands of repeated characters, > usually 'A' or newline or some charater from the command it received. > This is the same whether operated by the acm driver or a forced serial > driver. Assuming there is no bug in the acm driver, this means the > phone must deviate somehow from the spec and will need its own driver > to communicate properly. That could be bad. Have you tried contacting the manufacturer? Brad _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
