| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The MF691 appears to ignore E0 on the same line as some other stuff,
so really shut it up by sending E0 by itself.
|
|
|
|
|
|
CIND indexes returned from helper are 1-based, not 0-based, because
that makes it easier to match against the modem's unsolicited CIND
message.
|
|
BUG=6885
TEST=built modemmanager and cromo
Change-Id: Ib73a093b13da05948a2f1da8f051fe7c55682584
Review URL: http://codereview.chromium.org/3517013
(cherry picked from commit f447c8e1a0062500e1171e031cf4c8fef76ffd59)
Conflicts:
src/mm-modem-cdma.c
|
|
BUG=6885
TEST=inspect mm-modem.h, build cromo et al against new mm-modem.h
Change-Id: Id8c849b6cffbadb9d5d2aa4109257eb747cf9bb5
Review URL: http://codereview.chromium.org/3616004
(cherry picked from commit 3a50b8c28d155060ce035a1c6d5eadf3d91297a5)
|
|
Change-Id: I74451404361aa8bcc33ad0e66cbd5c6208222496
|
|
BUG=chromium-os:4560
TEST=tested using modified flimflam and cromo
Change-Id: I385abf8df340c26259810ea44c43680cc420c015
Review URL: http://codereview.chromium.org/3136020
|
|
Change-Id: I3af3ac8f60009f25b365c424d93258ded16f9212
|
|
Mea culpa. I moved it with 'mv', not 'git mv', thus resulting in total loss.
Change-Id: I94edfb9ca3b09d7956eea08971090ee022700d4d
|
|
Also, include the interface name in the method and signal names, to avoid name collisions. I have corresponding changes in the flimflam modemmgr plugin to accomodate the new names.
For a sample of the output, see ~ers/mm-modem.h
Review URL: http://codereview.chromium.org/2852010
(cherry picked from commit f9dbea25b8ba4414c77d6dfc94545bf7b5c26e68)
|
|
Prevent ModemManager from probing virtual devices before their
associated files exist in /dev tree.
Contributed by Nasser Grainawi <nasser@codeaurora.org>
Review URL: http://codereview.chromium.org/2118005
(cherry picked from commit 617660e3572a7b79ed83f9fc0fda89b7efcb2d4d)
Conflicts:
src/mm-plugin-base.c
Change-Id: Ie5e8b98fb6b6c69e294175523ef99c934092433b
|
|
Review URL: http://codereview.chromium.org/1508036
(cherry picked from commit f3432ada6bf8cd55f9dbdf050d510c53ce9f6687)
|
|
Amended: Install the files under their proper DBus names.
Review URL: http://codereview.chromium.org/1618004
(cherry picked from commit 89f7f05f1294485fa8b44cfdd3c9b0d924d45ac1)
Conflicts:
Makefile.am
Change-Id: I65b2b0c1b5e579bb5b1d5d5b390c3be2ae49543c
|
|
Review URL: http://codereview.chromium.org/1618004
Change-Id: Ib362c3dcdeb91472a64cf9edb6b4e0ddbcffe93a
|
|
Generate a header file for ModemManager with service names and paths,
method names and enums.
Review URL: http://codereview.chromium.org/1409001
|
|
Review URL: http://codereview.chromium.org/661471
(cherry picked from commit 8475eb44b7ea41afa823919b017a39d82b07a5a2)
Conflicts:
src/mm-plugin-base.c
Change-Id: I825886cad62a27acb39dfe74da7028d83adf692a
|
|
The kernel appears to add the device first without any parents,
then to move it to the correct place in the hierarchy, with its
immediate parent being the device's HCI controller. So we need
to capture the 'move' event too since that's when the rfcomm
device is finally usable.
|
|
|
|
Which requires that we turn it into a GInterface that MMModemBase
can implement, because dbus-glib does not allow attaching more
than one introspection glue structure to an object at a time.
Also implement the standard D-Bus properties changed signal.
|
|
Ignore devices that aren't completely configured by udev yet. If
ModemManager is started in parallel with udev, explicitly requesting
devices may return devices for which not all udev rules have yet been
applied (a bug in udev/gudev). Since we often need those rules to match
the device to a specific ModemManager driver, we need to ensure that all
rules have been processed before handling a device.
Do this by adding an item to the environment of each device that MM
might possibly be interested in, and ignoring devices that don't
have that. When the device is fully processed by udev, MM will get
an 'add' event and the device will have all rules applied.
|
|
|
|
|
|
Thanks to Niall Parker
|
|
(bgo #636040)
Some devices always reply with 99 for AT+CSQ when in UMTS mode (Linktop LW273)
so if the modem supports it, use CIND/CIEV instead.
|
|
|
|
|
|
Requires the sierra_net driver, which is included in the
2.6.34 and later kernels.
|
|
Some modems might not know their IP method until after the
modem object has been created.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-1 = no APN set, so use modem default. We'll have to fix a few
more things up for modems like hso/mbm that don't use ATDT and
require CIDs, but this gets us halfway there for other devices.
|
|
Rob McQueen saw a 10 here, which means SMS full. Handle that.
|
|
If the base class advertises that it implements an interface, it
really does need to implement all that interface's properties too.
Otherwise dbus-glib gets mad and can't look up the property information
for D-Bus Introspection.
|
|
We currently convert to and from the modem's set charset and always pass
'15' as the data coding scheme. Passing the correct data coding scheme
as third argument to CUSD only upsets the network. This contradicts 3GPP
TS 23.038. Other tools like gsm-ussd handle it the same way.
Network responses that require further actions are not yet implemented.
(some fixes and cleanups by Dan Williams)
|
|
|
|
This required dbus-glib 0.86 or later, which was released 2010-03-24.
|
|
|
|
Some devices (8775 specifically) get angry if you don't check for
a PS attach before dialing. The next time they try to connect,
they'll continuously report "searching" as the registration status
and return CME ERROR 30 (No Network Service) for lots of requests.
So initiate a PS attach (which should return OK if the modem is
already attached) before dialing, and if that fails cancel the
dial attempt.
See http://mail.gnome.org/archives/networkmanager-list/2010-October/msg00072.html
"I talked about this problem with a contact at SierraWireless. He said that
a firmware upgrade will not help in this case. But what can help is checking
for PS attach and dial only if PS attach status is attached. Dialing without
PS attach can bring modem into unwanted condition that sometimes restart is
needed to recover."
|
|
|
|
|
|
Checking PIN status makes sure the SIM is initialized, and
that has to happen before we try to read the SIM for the
ICCID. So move PIN checking before getting the ICCID, and
retry the ICCID at least once for odd cards like Gobi 1K
that seems to need one more try right after it's done
booting up.
|
|
Depending on when the core requested the ICCID, the port may or may
not be open. Stuff that needs an open serial port needs to make sure
that the port gets opened itself.
|
