| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
Most modems don't support it and we're ignoring the error message
anyway, so don't bother with a callback for its result.
|
|
|
|
If the modem returns an error (like "+CME ERROR: incorrect password"
or even just ERROR) make sure we recheck PIN status and thus also
recheck the number of unlock retries instead of just returning the
error to the caller.
|
|
|
|
Nobody seems to know what the number means, but at least recognize
them as errors.
|
|
|
|
More info:
https://bugzilla.redhat.com/show_bug.cgi?id=585394
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1172
dbus-glib was not properly enforcing the 'access' permissions on
object properties exported using its API. There were 2 specific bugs:
1) dbus-glib did not enforce the introspection read/write property
permissions, so if the GObject property definition allowed write
access (which is sometimes desirable), D-Bus clients could modify
that value even if the introspection said it was read-only
2) dbus-glib was not filtering out GObject properties that were
not listed in the introspection XML. Thus, if the GObject defined
more properties than were listed in the introspection XML (which is
also often useful, and MM uses this quite a bit) those properties
would also be exposed to D-Bus clients.
To fix this completely, you need to:
1) get dbus-glib master when the patch is commited, OR grab the
patch from https://bugzilla.redhat.com/show_bug.cgi?id=585394 and
build a new dbus-glib
2) rebuild ModemManager against the new dbus-glib
|
|
Work around an API break in glib.
|
|
Sometimes the primary mode will be 1X (and thus the Call Manager
will report 1X system mode) but the HDR subsystem will be registered
and idle. Figure that out and report that EVDO is registered too
in that case, since the modem will just flip over to EVDO when
the data call starts.
|
|
|
|
Apparently g_convert() can still return garbage that's not valid in
the character set you're converting to (???). But even if we don't
need to convert the operator name, make sure it's valid UTF-8 before
we go shoving it through D-Bus.
|
|
Need to emit the D-Bus API property name, not the GObject property
name for a few things on the Location interface.
|
|
|
|
Depends on dbus-glib 0.86 + this patch:
https://bugs.freedesktop.org/show_bug.cgi?id=28835
Still have to do the bits that allow plugins to add other
location capabilities, but that can come later.
|
|
|
|
|
|
Cleanups and authorization checks by me (dcbw).
|
|
|
|
Returns the ID of the operator that issued the SIM card.
Cleanups and get_mnc_length_done() by me (dcbw).
|
|
|
|
|
|
Which reports the # of attempts remaining for the current PIN required
by the device or SIM.
Some modifications/cleanups by dcbw.
|
|
Found by jklimes. If some plugin already supports this port, it's
pointless to let Generic figure out if it supports the port since
we're just going to hand it to the other plugin anyway.
|
|
|
|
Prevents crashes when the callback info completes when the modem is
removed, plus it's the right thing to do anyway...
|
|
Some devices (Blackberries) always respond to AT+CREG with ERROR,
but will respond to AT+CGREG normally. Ugh. Handle that by
using the PS registration status from AT+CGREG if we don't have
a valid CS registration status at all.
|
|
The flash function could be called when the port was closed, and since
the flash function would only be canceled when the port was open,
it could trigger after the port object was destroyed.
|
|
|
|
|
|
|
|
Distributions should set dist-version at build time with the
package version and revision, so for RPM-based distros you'd
--with-dist-version=%{version}-%{release}
which will be printed out on MM startup to help debugging.
|
|
|
|
|
|
See also d5ca82eade4c341a18a72e6f16c9db4ee34be4d5
|
|
Since MMModem is an interface and doesn't store stuff like the
modem's physdev internally (since it's an interface) these things
are handled via GObject properties. And since g_object_get()
returns allocated values, we need to free the returned value
from mm_modem_get_device() after we're done with it.
|
|
|
|
There are some cases where flashing the primary port doesn't work
either due to stupid modem firmware or crappy kernel drivers. So
if we have a secondary port, try sending the PDP deactivation
command to the secondary port first, and if that fails send it
to the primary port after the primary port gets flashed. This
increases the chances that the +CGACT request will be successful.
Some modems (Huawei, ZTE) don't like +CGACT on the secondary port,
but when that fails, the code falls back to previous behavior of
flashing and sending CGACT to the primary port.
|
|
Some phones like the T630 don't put a space after the ':'.
|
|
The argument passed to the handler is a GByteArray, not a
GString. Encountered with Option iCON Icera-based devices,
but could also be possible with Sierra devices.
|
|
|
