Anyone got: 
umsm0 at uhub7 port 2 configuration 1 interface 0 "Sierra Wireless Sierra Wireless MC5720 Modem" rev 1.10/0.01 addr 2
ucom0 at umsm0
To work on OpenBSD?

I get basically no output from the modem using this in /etc/remote:
mobile:\
        :at=hayes:dv=/dev/cuaU0:dv=/dev/ttya:tc=direct:tc=unixhost:

# sudo tip remote
connected

And then I can type AT all day long and get no response.  The modem
isn't activated but I don't want to go spend money on activating it
unless I know if that is what is causing it to not respond.

Something else weird is that if I fart enough with tip and stuff to get
to the modem and reboot with it on it hangs the IO subsytem.  Not sure
why a serial port is sitting on IPL_BIO but that is a different story.

[ message continues ]

On Mon, 14 Jun 2010 20:17:44 -0500 Marco Peereboom <slash@peereboom.us>

As mentioned off list, a vast number of the early "data card" designs
actually have *multiple* serial ports, but only one of them is usable as
a typical AT-Command modem. The other serial ports on the device(s) can
only speak proprietary protocols and are used for BS "Management" and
"Monitoring" functions (e.g. constantly checking/reporting signal
strength). The umsm man page clearly mentions these other unusable
ports since there's no definitive way to tell which port is usable as a
modem.

If a serial port on the device does not respond to AT commands, you have
the wrong port. If it's the only available port on the device, then you
need to tweak the umsm sources to make it look for multiple ports on
your device. If after finding all the available ports on a device, you
cannot find a port that talks AT commands, then either the device is 
broken or you need some secret sauce to make the device go back to
speaking normal AT commands (rather being in "proprietary mode").

Additionally, many modems support "profiles" which is a fancy way to say
the firmware in the device remembers the settings you previously gave
it. Clearing the various types of profiles/settings is often
vendor/device specific. Some of the more common AT commands for
resetting a device are:

	ATZ
	AT&F
	AT+CFUN=1

Since you will need access to a MS-windows system to do the required 
"activation" nonsense before the device will work with a given providers
network, you should look at the device to see what *.inf file is being
used to define how the device is controlled.

For example, the Pantech (ZTC) UMW190 I have here uses the
C:\windows\inf\oem33.inf file as its definition (seeable through device
properties or Modem/PPP logging if enabled). Look in said file for the
"Reset" entry to figure out the proper AT command..

By comparison, Sierra Wireless is one of the most open source friendly
of all the "data card" vendors so digging ...
[ message continues ]

On Wed, Jun 16, 2010 at 5:56 AM, J.C. Roberts <list-jcr@designtools.org>

All Ericsson based modems can be reseted with AT+CFUN=1 (or if you
want you can AT+CFUN=0 to turn it off and then AT+CFUN=4 to turn it on
in UMTS mode).
A lot of other cards support this also.

BR
Dunceor

[ message continues ]

the full AT command sets are available somewhere here:

http://www.google.com/search?q=at.commands+site:3gpp.org


Note that a large number of the 'modems' these days, expose two serial
interfaces, and only one will listen for AT commands, until correct
initialisation is done...


/Pete




[ message continues ]

this may be common in the USA, but isn't needed everywhere.

[ message continues ]

On Mon, 14 Jun 2010 20:17:44 -0500 Marco Peereboom <slash@peereboom.us>

I spotted something interesting that I've never seen myself... It seems
some of these "mobile data cards" require some kind of mode switch for
them to be in a usable state (read: the serial port that accepts
AT Commands is only visible/usable in a certain mode).

Some of the linux folks have been working on mode switching code:

http://blogger.ziesemer.com/2008/10/alltel-um175al-usb-evdo-ubuntu.html

http://www.draisberghof.de/usb_modeswitch/

As you can read in the links above, the mode switching magic seems to be
at least somewhat device dependent. 

	jcr

-- 
The OpenBSD Journal - http://www.undeadly.org

[ message continues ]

This mode-switching they're doing in userland with libusb (by letting
it talk to devices which already have a kernel driver.....) is the same
sort of thing we do in the kernel with the UMSM_FLAG / DEV_UMASS* stuff.

[ message continues ]