Otherwise the attached state gets to be set before the actual LTE
automatic context is ready. This triggers a race between connman
and ofono: connman sees status attached before the context is active
so connman will try to activate another context with same apn and will
fail over and over again.
The spec supports UCS2, but in reality UTF-16 is used, which supports
4-byte characters, which could be split into different message
fragments. Accumulate the entire UTF-16 message before converting to
UTF8.
Author: Martin Jones <martin.jones@jolla.com>
This implementation can only get/set the default APN setting. But
anything expected for this atom is there:
* D-Bus interface
* sync-ing settings to/from file
* interaction with driver
... in pri_deactivate_callback
This prevents attached state from getting stuck at 0 like this:
1. Context deactivation is initiated over D-Bus, ctx->pending is set
2. Attached becomes FALSE, context is still marked as active
3. Attached becomes TRUE, gprs_attached_update sets GPRS_FLAG_ATTACHED_UPDATE
4. Deactivation completes, attached is 0, driver_attached is 1
Futher network status updates don't call gprs_attached_update because
driver_attached is still 1, so attached is staying 0 until we lose the
data registration again which may not happen for quite a long time.
query facility during initialization is modified from back
to back invocation to chain manner to keep it inline with
RIL design. All vendor RIL does not support back to back
handling since RIL telephony framework sends the request
synchronously.
The set_band method takes two parameters for band settings, one for gsm
and one for umts. When loaded from storage, and they are not set to
defaults, the band variables can get out of sync when setting the
GsmBand and UmtsBand properties.
After input PIN wrong 3 times, sim main state (include spn_watches)
is freed. but the watch id still be kept by other atoms (network and
gprs), when remove the atom, it will try to remove the watch from
spn_watches, ofono daemon will crash.
rs->imsi is only freed when rs->settings is true. So tweak the logic
inside radio_load_settings to only strdup the imsi when settings
creation has succeeded.
In some cases it is possible that a context is opened after a detach
event has been received, and right before an attach, depending on the
modem. We make sure that those contexts are removed to keep
consistency.
It works by looking for a context with the same APN and tries to use
that. Otherwise it will create it's own.
Then it assigns a gprs context driver and calls it's read_settings if
it exists.
When issuing a Scan() in poor reception while attached to an operator it's
fully possible to get no results, which causes the attached operator to be
cleaned up. In certain scenarios this would cause a use-after-free as there
are still references to this operator.
Transfer the attached operator to the new list regardless of removal caused
by the Scan() results.
This matches the behavior described by the documentation the signal
value returned by the code. This was causing a headache when using
stricter D-Bus wrappers like dbus-c++.
In situations where location changes rapidly, a use-after-free condition
can occur. What happens is that the timeout leaks and then the cbs
struct with the callback is cleaned up, resulting in a SIGSEGV when the
callback occurs from the glib loop.
When the voicecall atom is unregistered we remove all HFP support as
well but were supplying a zero as value to the emulator status
callbacks which caused the process to crash as we were dereferencing
the supplied value always and not respecting a zero as indicator to
reset.
When registering audio cards for the handsfree and gateway roles we
need a way for our users to differentiate between both to decide which
of them they start using for their purpose.
The kernel simply puts a null terminator at index 15 prior to ifr_name
processing. So we do the same.
Original report by:
Sabas Rosales, Blanca E <blanca.e.sabas.rosales@intel.com>
Buffer not null terminated (BUFFER_SIZE_WARNING) buffer_size_warning:
Calling strncpy with a maximum size argument of 16 bytes on destination
array ifr.ifr_ifrn.ifrn_name of size 16 bytes might leave the
destination string unterminated.
92 strncpy(ifr.ifr_name, interface, IFNAMSIZ);
Function: ag_features_list
static const char *list[10]; (Out of bounds write, line 75)
Incrementing i the value is now 10, for “hf-indicators”
Reported by: blanca.e.sabas.rosales@intel.com
TP-OA max length comparisons were incorrect because TP-OA's 7-bit
coded octets transport eleven 8-bit chars. The current code assumed
only 10 chars were possible.
The patch
- increases the array size to 23, (maximum of 22 bytes for UTF8
encoding + null terminator)
- Updates the sanity check to account for the correct maximum
- For encoding, checks the maximum length in UTF8 characters instead of
bytes
Init allocates a SCO audio socket always. oFono should do that
with bluez5 but not with bluez4. This patch starts the refactoring of
the handsfree_audio_manager init/cleanup functionality.
On some architectures the SimManager.Retries property was getting bogus
values. This is because we were sending an array which pointed to int
values instead of the expected unsigned char values.
This fix allocates a temporary array of unsigned chars to hold the
actual D-Bus values being sent. Additionally, the dictionary array is
changed to point to the temporary unsigned char based values instead of
the raw 'int' based retry values.
EF_PNN was not being read properly (see TS 24.008, section 10.5.3.5a,
for network names format), which affected the displayed PLMN name for
some MVNOs. Some modems already read the file and return the right
string: these do not show the problem.
The current bitshift logic in idmap incorrectly uses
the literal 1 for the value to shift in idmap_alloc(),
idmap_take(), and idmap_alloc_next(). This causes the
resulting value to be an int instead of a long, which
results in the wrong bit being set once the number of
bits to shift operand exceeds sizeof(int). Also
on some platforms, the behavior of the left bitshift
operator is undefined when this overflow occurs.
As we won't allow any card to be registered when the kernel doesn't
support defer_setup, we don't need to have the listening SCO socket
open in this case.
If the kernel doesn't support defer_setup for SCO, we shouldn't allow
cards to be registered, because in that case we won't be able to
properly send the file descriptor to the Agent.
So the value might be used directly for D-Bus property emission.
Otherwise D-Bus asserts and screws itself with:
ofonod[7427]: src/sms.c:handle_mwi()
process 7427: arguments to dbus_message_iter_append_basic() were
incorrect, assertion "*bool_p == 0 || *bool_p == 1" failed in file
../../dbus/dbus-message.c line 2549.
It's not possible to be both greater than '9' and less than '0'. This
would lead to accepting things like "#$33#" as activation and "*$33#" as
deactivation, even though the string makes no sense.
src/stk.c: In function ‘__ofono_cbs_sim_download’:
src/stk.c:283:45: error: argument to ‘sizeof’ in ‘memcpy’ call is the
same expression as the source; did you mean to dereference it?
[-Werror=sizeof-pointer-memaccess]
memcpy(&e.cbs_pp_download.page, msg, sizeof(msg));
^
In the case that ofono_handsfree_card_connect_sco() is called outside the
context of a .Connect() call, there's no message we need to reply. This
happens, for example, when the HFP AG plugin initiates a SCO connection when
it receives an AT+BCC command from the HF.