This likely has no effect, but just make sure the regex stops
grabbing message content when it hits the CF/LF that terminates
the message content in text mode.
This method will try to convert the input string to UTF-8. The input string is
supposed to be in the given charset; or otherwise is supposed to be the hex
representation of the string in the given charset.
The introspection data specified the Send() method to return
an array of unsigned integers, presumably the indexes of the
messages just sent. But the code wasn't doing that, leading
to a crash when dbus-glib tried to interpret garbage on the
return.
The problem is that sms_send_auth_cb() gave async_call_done()
as the callback for sending the SMS, but that method just calls
dbus_g_method_return() with no return arguments. dbus-glib
interprets the arguments of dbus_g_method_return() according
to the XML introspection data, and thus it was attempting to
read the non-existent argument as an 'au' and getting garbage.
Fix that by actually returning an array of message indexes from
the SMS send code, and propagate that back to the SMS dbus
code so it can return something sensible.
The first byte of the PDU is the SMSC length, but it's not
the padded SMSC length. So we need to subtract the actual
byte index of the start of the message from length of the
PDU, and since the PDU creation function knows all about
where the SMSC address stops and the message begins, just
have it return that length instead of making the callers
calculate it.
Tests that the last septet (packed in an octet by itself)
doesn't get left off the message like the old code used to
do before "core: fix some bugs in GSM7 packing code".
The existing gsm_pack() had a bug where if the last
septet should be in an octet by itself, that last
octet wouldn't be added. Plus, kinda pointless to
use a GByteArray here when we already know what the
length will be through simple arithmetic.
We can also simplify the function too.
Furthermore, there weren't any testcases for starting
packing at an offset other than zero, so add one.
There's no encoding information about 8-bit SMS messages,
and they are often binary things like ringtones or voicemail
indicator commands. Since there's no point to our parsing
them just let clients deal with it.
Various bits of the code didn't check if response was valid
or not during error conditions, and when an error occurs
sometimes it'll be NULL (since not all errors are translated
errors from the modem, some are serial or general ones). We
have to make sure we don't try to use response->str when
response doesn't exist.
Found in the generic CDMA code likely as a result of
d5d9eec2b5 but was a bug long
before that commit happened anyway.
Change the error handling to be a bit more like what appears to have
been intended: if constructing the regex fails, report an error and
return. The existing code looked like it was set up to do this, but
wasn't quite wired together, and had process-terminating calls
(g_error()) followed by other code.
Change-Id: I4a7cee8fe01291976edc2e343fcbeb73e882f20b
First, arrange for received/complete signals to be sent by calling
cmti_received_has_sms() with the message properties even if the
message isn't complete yet.
Second, make the operation of the List command's multipart message
handling independent of message order by doing one pass to insert the
messages into the cache and second pass to retrieve the complete messages.
Change-Id: I3dcae940d71aec3ddb65c508675f710d1567b0e2
Reporting errors instead of just returning permits routines like
mm-generic-gsm.c:simple_get_status() to work again, as their callbacks
get the error they are expecting. To make this work, adapt get_csq_done()
to handle a NULL response when error is set, and make sure that multiple
errors don't step on each other in the mm_callback_info_chain() sequence
created by simple_get_status().
Change-Id: Ie3a72b1ce71b7f117e8b1f3da7a406c4d2da9e02
Some modems don't allow most commands when they are PIN locked, so
the initial facility lock check errors out. Check the locks again
after the SIM is unlocked.
The property EnabledFacilityLocks on the .Modem.Gsm.Card interface
is a bit mask that indicates which of the various personalization
codes from 3GPP TS 22.022, plus the SIM PIN lock and SIM PIN2 lock,
are enabled. The set of facility locks supported by the modem is
determined at the time the modem is initialized, and the state of
each supported lock (enabled or disabled) is determined. When the
state of a lock changes, a property-change signal is sent out. Note
that ModemManager only supports enabling and disabling SIM-PIN, via
the EnablePin method on Modem.Gsm.Card.
Added a PinRetryCounts property on org.freedesktop.ModemManager.Modem.
This is dictionary that records the number of PIN tries remaining
for each of the possible PIN code types for which the modem is
capable of reporting the count. Also, these counts are kept up
to date across ChangePin and EnablePin operations, not just when
an unlock is attempted.
Aleksander Morgado
Dan Williams
Thomas Tuttle
Nathan Williams
Vitaly Gimly
Jiří Klimeš
Nathan Williams
Eric Shienbrood