| Age | Commit message (Collapse) | Author |
|---|
|
Also, MEID->Meid to follow standard D-Bus property semantics.
|
|
If the device only has one AT port that's being used for data and
thus we can't do more specific registration checking in MMGenericCdma
using AT commands, but generic registration checking was successful,
just use the less specific state.
Previously, an error would be returned when no AT port was available
even though less specific QCDM registration checking worked. That
was just stupid.
|
|
If the modem's IP Method changes after construction because the
modem's full capabilities were only discovered after it was created,
make sure the change notification gets emitted.
|
|
|
|
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
|
|
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
|
|
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/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.
|
|
(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.
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
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.
|
|
An obfuscated SimIdentifier that may be available before the PIN has
been entered, for use in auto-unlocking a device. If this value is
present, it should be used in preference to DeviceIdentifier as it
is SIM-specific like the PIN code.
|
|
|
|
|
|
These aren't added to the udev device database by anything yet
(though they should be) so grab them manually.
|
|
|
|
Pass the device's hardware IDs through modem creation and use them
when calculating the device's identifier. Add a bunch of testcases
for real hardware to ensure we don't break the device ID in the
future unless we really want to.
|
|
This is computed before any PIN is entered, and thus before we can
usually get IMEI or MEID/ESN out of the device in many cases. It's
therefore not the same as EquipmentIdentifier.
This is intended to be used by UI programs for matching devices with
PIN numbers for automatic unlocking. While the PIN number is actually
*SIM* specific, no modems allow access to the IMSI before the PIN is
entered, and thus we cannot actually match the PIN with the SIM. The
device ID is the next best thing we can use and should allow auto
unlocking in most cases.
|
|
We don't care about the error if we have a QCDM port.
|
|
Ensure that valid HDLC frames that are not valid QCDM frames
are correctly rejected, and that their data is correctly
discarded.
The core bug was that Sierra CnS frames have leading and trailing
HDLC frame terminator bytes (0x7E), and the code was incorrectly
treating the leading terminator as the end of a frame, not the
beginning. Thus it would consider the outstanding serial request
finished without actually parsing the response packet.
Now, we make sure we don't tell the serial receive code that
we have a full QCDM frame until we actually do have one, which is
at least 3 bytes + 0x7E.
|
|
|
|
Test that a Version Info request/response works as expected, and
add a testcase for a bug where specific Sierra CnS responses to
the Version Info request do not properly return an error when
attempting to parse the response as a QCDM packet. Fix for the
second thing forthcoming.
|
|
For better unit testing.
|
|
Aids in unit testing
|
|
To enable better unit testing of MMSerialPort and subclasses
behavior.
|
|
This is the real fix for 81d0fd148f8c72a2e50b4e6fe82496daa28a91cc.
Some devices don't interact well with the option driver or the usb-serial
layer; they don't respond to the USB data requests and thus data never
gets written to that port. When close(2) is called, that data is still
pending and so the tty layer waits 30 seconds before returning from
the close. This is the 'closing_wait' value, which unfortunately is
not able to be modified by ModemManager because most serial drivers
for 3G devices don't implement the .ioctl handler or its TCIOSSERIAL
option to change closing_wait.
This goes along with a kernel patch to various drivers to enable
the TIOCSSERIAL ioctl to modify closing_wait which will be posted
soon.
|
|
Some devices don't interact well with the option drivr or the usb-serial
layer; they don't respond to the USB data requests and thus data never
gets written to that port. When close(2) is called, that data is still
pending and so the tty layer waits 30 seconds before returning from
the close. This is the 'closing_wait' value, which unfortunately is
not able to be modified by ModemManager because most serial drivers
for 3G devices don't implement the .ioctl handler or its TCIOSSERIAL
option to change closing_wait.
Print out open/close timestamps to help debug this issue and get a
list of modems that have this problem.
|
|
To test spaces between some members of the response.
|
|
It's only really used for phonebook and SMS PDU mode in the specs,
which we don't do yet, so if this is the only charset the device
supports we'll try to use it.
|
|
|
|
|
|
|
