The detach_shutdown method is invoked to unconditionally release
an active context. For QMI, this is equivalent to a call to
deactivate_primary.
This patch makes the callback to deactivate_primary optional and
implements detach_shutdown to simply call it. When there is no
callback, the stop_net callback notifies ofono about the context
release via an asynchronous ofono_gprs_context_deactivated() call.
For LTE networks, a default bearer is automatically activated when
the modem registers to the network. QMI modems, however, do not
automatically enable the network interface just because the bearer
exists; a call to "start network" needs to be made in order to
get the packet handle before get_settings will return any data and
the network interface can be configured.
This patch makes read_settings call "start network" in order to
enable the interface for the default bearer. No new bearer will
be created with this call and the settings for the bearer will come
from the default profile, irregardless of what parameters are passed
to the "start network" method.
For LTE, a context is created automatically when the modem registers
to the network. The read_settings function is called for these
automatic contexts to get their configuration.
The GPRS context needs to be configured with connection parameters when
the bearer has been established. This was only partially implemented, so
this patch adds additional parameters to those passed to the context.
Calling the ps_state/cs_state alternatives *ATTACH_STATUS* was confusing
because there is also a status field in the *serving_system structure.
This patch does a minor rename and adds the appropriate definitions for
the status field.
qmi_device_shutdown allocated a new orphaned data structure and kicked
off a timeout to wait for the shutdown to complete. The logic was quite
racy, but the main issue was that the timeouts could not be canceled
when the underlying qmi_device object was destroyed. This resulted in
crashes.
This patch switches to first-past-the-gate mechanism. Since only the
modem driver should be issuing a qmi_device_shutdown call, this should
not be a limitation. The shutdown source is then tracked on the
qmi_device object itself and is canceled when the qmi_device object is
freed.
As an added bonus, the shutdown_destroy callback should now actually
function. Before it was simply never called.
struct discovery was allocated for every discovery procedure that was
kicked off, which itself allocated a structure. This patch uses a
class/subclass concept to only allocate a single structure per discovery
procedure.
This function was never removing discovery instances because it was looking
them up in the wrong list. This led to some strangeness with the discovery
callbacks being invoked after the "failure" timeout of 5 seconds and
consequent failures with everything getting out of sync.
With this patch we fix the lookup to use the correct queue. There's also
a double-free in the function that was never being hit before because the
lookups never succeeded; fix that as well.
With this, service discovery and creation work as expected when testing with
an EC21.
Telit AT modem firmware (tested with UE910-EUR) generates
+CGREG: 0\r\n\r\n+CGEV: NW DETACH
after a context is de-activated and ppp connection closed.
Then, after a random amount of time (observed from a few seconds
to a few hours), an unsolicited +CGREG: 1 arrives.
Attempt to fix the problem, by sending AT+CGATT=1 once.
This does not re-activate the context, but if a network connection
is still correct, will generate an immediate +CGREG: 1.
There are various device & service discovery tasks that are initiated
based on a qmi_device object. qmi_device object does not currently
keep track of these tasks. Unfortunately the qmi_device object can
go away at any time, and these tasks can become orphaned.
The result of this can lead to crashes. E.g. a discovery task timeout fires
after the qmi_device object has been destroyed. Since the object is no
longer valid, any accesses to it will likely result in a SEGFAULT.
This patch attempts to track all discovery tasks on the qmi_device
object itself, so that they can be cleaned up properly. This patch does
not handle the qmi_device_shutdown functionality.
Telit QMI modems can return non-utf-8 characters in plmn-desc.
Observed with LE910-SVG and Verizon. When that happens, libdbus
will abort ofono.
If non-utf-8 characters are detected, use mccmnc string.
LTE modems (observed with Telit LE910 V1) can power on
already registered to a network. In that case, the SS_INFO
change notification will never arrive, and the gprs driver
will never be marked as attached.
To avoid this situation, read SS_INFO at probe time, and if
registered, mark the gprs driver as attached.
This was introduced by the previous patch:
drivers/qmimodem/devinfo.c: In function ‘get_ids_cb’:
drivers/qmimodem/devinfo.c:129:14: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration]
if (!str || strcmp(str, "0") == 0) {
Command read_file_info on MC7304 always fails.
Using qmicli or AT command, I am able to read file info.
Qmicli command is:
qmicli -d /dev/cdc-wdm0 --uim-get-file-attributes=0x3f00,0x7fff,0x6fad
[(null)] Successfully got file '/dev/cdc-wdm0' attributes from the UIM:
Card result:
SW1: '0x90'
SW2: '0x00'
File attributes:
File size: 4
File ID: 28589
File type: transparent
Record size: 0
Record count: 0
Read security attributes: (always) (null)
Write security attributes: (single) adm
Increase security attributes: (always) (null)
Deactivate security attributes: (single) adm
Activate security attributes: (single) adm
Raw: 62:17:82:02:41:21:83:02:6F:AD:8A:01:05:8B:...
After a check of parameters sent by qmimodem driver and qmicli,
the only difference is on parameter "Session Information".
Session type sent by qmimodem driver is 'Card on slot 1'.
Session type sent by qmicli command is 'primary-gw-provisioning'.
Changing session type in qmimodem driver fixed problem (on this modem).
Comparing with what is done by qmili command
Some modems do not support AT+CGDATA="PPP",X to enter data state.
Use AT+CGDATA=? to detect these modems and for them use ATD*99***X#
to enter data state.
drivers/rilmodem/stk.c: In function ‘ril_stk_probe’:
drivers/rilmodem/stk.c:210:18: error: ‘data’ is used uninitialized in
this function [-Werror=uninitialized]
struct cb_data *cbd = cb_data_new(stk, NULL, data);
sending RIL_REQUEST_REPORT_STK_SERVICE_IS_RUNNING after
stk atom is created so that modem will inititialize
sim toolkit by sending terminal profile to sim.
During gprs-context driver probe function, check kernel device driver
data format and modem low level data format.
If they are different, align kernel device driver data format on
modem low level data format.
If an error occurs during this process, continue probing without error.
This is inspired by what is done in qmicli and qmi-network (package
libqmi).
Add a way to get and set data format expected by kernel device driver.
This is inspired by what is done in qmicli (package libqmi).
It does not use QMI protocol but a sysfs exported by kernel driver.
To use this feature, kernel version must be equal or more than 4.5.
Network Control Model is a new Communication Device Class
protocol for exchanging Ethernet frames over USB.
NCM is intended to be used with high-speed network
attachments such as HSDPA and LTE data services.
Add a new location-reporting driver for Gemalto Cinterion modems based
on telit implementation + use it in gemalto plugin. It supports
activation of GNSS engine (Request) with command AT^SGPSC. This driver
is tested on PHS8. NMEA frames are accessible on /dev/ttyUSB1.
Retry command QMI_UIM_GET_CARD_STATUS during query_passwd_state if a
temporary error status has been detected.
This happens with a MC7430 modem when query_passwd_state is called just
after PIN is entered.
CGDCONT result parsing fails if first list contains several ranges. For
example with modem Cinterion PHS8:
AT+CGDCONT=?
+CGDCONT: (1-17,101-116),"IP",,,(0),(0-4)
Solution: read first range and jump to second list instead of trying to
close the brackets.
Password state and number of retries asked to modem using
QMI_UIM_GET_CARD_STATUS command rather than remembered after initial
QMI_UIM_GET_CARD_STATUS command.
Add read_imsi feature to qmimodem sim driver.
This is based on DMS service.
On MC7430, this is mandatory to be able to use this driver for GPRS
connection because reading IMSI via EF reads fails.
QMI notification messages handlers are never called on MC7430 without this fix.
- Do not test transaction id before calling notification handler. On MC7430,
notification messages contain a not null transaction id (starts with 1,
increased at each message for a particular client).
- On MC7304 transaction id in notification messages is always 0.
Get current signal strength (type: 0x01), not list of other signals strength
(0x10)
Without this fix:
- I can't get a signal strength on MC7430 because list does not exist
(only one signal strength).
- On MC7304, result is wrong
- useless return at the end of a function
- mixed tabs & spaces for indentation
- over 80 characters for the comment
- line > 80 characters due to access technology conversion. Replaced
with a direct assignment.
drivers/ubloxmodem/netmon.c: In function ‘req_cb_data_unref’:
drivers/ubloxmodem/netmon.c:131:10: error: ‘return’ with a value, in
function returning void [-Werror]
return NULL;
This adds a netmon driver for ublox. The driver support both +COPS and
+CESQ commands to return the previously added ofono netmon types:
RSCP: Received Signal Code Power
ECN0: Received Energy Ratio
RSRQ: Reference Signal Received Quality
RSRP: Reference Signal Received Power
Current revision makes the driver use ref countig when chaining multiple
AT commands.
The U-Blox documentation specifies the following:
* get interface ip and dns from +CGDCONTRDP
* get gw ip and netmask from +UIPADDR
However, different firmware versions have different befaviour:
* On newer firmware, +UIPADDR returns error. But it's possible to configure
gateway ip == ipterface ip (read from CGDCONTRDP).
* On older firmware, we can actually use the commands specified in the
docs.
This patch runs +CGDCONTRDP, configures everything and then tries to run
+UIPADDR. In that works, reconfigures gw ip and netmask.
Adds U-Blox Toby L2 driver for setting the default APN via the
+UCGDFLT command. Currently only IPv4 is supported. APN is
not stored to modem's non-volatile memory. oFono will manage this
default APN via it's config storage.
When receiving an empty default APN, the value is reset.
strtol clamps returned value between INT_MIN and INT_MAX, causing
invalid value (255.255.255.127) being reported for any address
if last octet > 127 when sizeof(long) == 4.
split ril_pin_change_state_cb based on functionality w.r.t.
facility lock, puk and pin. Rename ril_pin_change_state to
more appropriate name ril_set_facility_lock and rename
ril_pin_change_state_cb to ril_enter_sim_pin_cb.
addrs variable seems to be used whenever multiple addresses are being
references. Either as a strv or a compound string separated by a
separator. In these cases addrs was used for a single address, which
was confusing.
Some phones with an active and waiting call at the time of HFP SLC
establishment, may send call waiting notification before all calls
are synchronized. This will lead to call Id mismatch because call
object is created with assumed Id 1 and not Id assigned by the phone.
In example below waiting call is created with Id 1 but in AT+CLCC
this phone returns active call as call with Id 1, and waiting as 2.
< \r\n+CCWA: "+1234567890",145\r\n
< \r\n+CIEV: 2,1\r\n
drivers/hfpmodem/voicecall.c:ccwa_notify() ccwa_notify: +1234567890 145 0
src/voicecall.c:ofono_voicecall_notify() Got a voicecall event, status: 5, id: 1, number: +1234567890 called_number: , called_name
src/voicecall.c:ofono_voicecall_notify() Did not find a call with id: 1
> AT+CIND?\r
< \r\n+CIND: 1,1,1,4,0,2,0\r\n\r\nOK\r\n
src/network.c:ofono_netreg_status_notify() /hfp/org/bluez/hci0/dev_60_AF_6D_F7_8E_37 status 1 tech -1
> AT+VGS=7\r
< \r\nOK\r\n
> AT+VGM=7\r
< \r\nOK\r\n
> AT+CLCC\r
< \r\n+CLCC: 1,1,0,0,0,"+9876543210",145\r\n
< \r\n+CLCC: 2,1,5,0,0,"+1234567890",145\r\n\r\nOK\r\n
src/voicecall.c:ofono_voicecall_notify() Got a voicecall event, status: 0, id: 1, number: +9876543210 called_number: , called_name
src/voicecall.c:ofono_voicecall_notify() Found call with id: 1
src/voicecall.c:ofono_voicecall_notify() Got a voicecall event, status: 5, id: 2, number: +1234567890 called_number: , called_name
src/voicecall.c:ofono_voicecall_notify() Did not find a call with id: 2
src/voicecall.c:ofono_voicecall_mpty_hint() ids: 0
For now the driver works only with bridged mode for 2G/3G.
Once it activates the context it reads the ip, netmask,
gw, dns and sets them in the context settings.
Besides exceptions below, act like normal U-Blox devices.
gprs-context: don't set auth for TOBY L2. U-Blox Toby L2
doesn't support PAP/CHAP APN auth method.
atmodem: TOBY L2 supports only CMER mode 1. Also chaged original
mode variable to ind, which is a more appropriate name.
mode is what is being set first.
An issue with iPhone 5C iOS 9.2 triggers desynchronization in call
states. When an active call is put on hold and another call arrives,
it is in WAITING state. It should be possible to answer it by issuing
AT+CHLD=2 but the phone changes its state to INCOMING so ATA should be
used. This change is advertised by sending callheld:2 event, but it is
not handled. This event can be used to trigger CLCC poll to synchronize
call states.
+CIEV: 3,1 <- first call arrives
AT+CLCC
+CLCC: 1,1,4,0,0,"01234567890",129
OK
RING
+CLIP: "01234567890",129
ATA
OK
+CIEV: 2,1
+CIEV: 3,0.
AT+CHLD=2.$ <- first call is put on hold
OK
+CIEV: 7,2 <- notification confirming that call #1 is on hold
+CCWA: "09876543210",129,1 <- second call arrives
+CIEV: 7,2
+CIEV: 3,1
AT+CLCC
+CLCC: 1,1,1,0,0,"01234567890",129
+CLCC: 2,1,5,0,0,"09876543210",129 <- new call is still in WAITING state
OK
+CIEV: 7,2 <- phone iternally promotes WAITING call to INCOMING
AT+CHLD=2 <- there is no WAITING call anymore, ATA should be used
+CME ERROR:3
The return value from a RIL_REQUEST_GET_FACILITY_LOCK
is the TS 27.007 service class bit vector of services
for the specified barring facility. The value canf be
zero, which indicates "disabled for all".
During the re-factoring of rilmodem's sim atom
messaging code, the sim_status_cb function's
RIL tracing code was converted to DBG calls.
This change adds the same prefix to DBG/trace
calls when a single message's parameters span
more than one DBG call. This makes it easier
to filter out trace messages when looking at a
log file.
Driver for modems that are accessed through the Android Radio Interface
Layer (RIL) for telephony, using the gril library. The driver is almost
feature complete with some exceptions, being CBS and SAT the most
prominent.
Co-authored-by: Tony Espy <espy@canonical.com>
Co-authored-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
Co-authored-by: Alfonso Sanchez-Beato <alfonso.sanchez-beato@canonical.com>
Co-authored-by: Islam Amer <islam.amer@jollamobile.com>
Co-authored-by: Jussi Kangas <jussi.kangas@tieto.com>
Co-authored-by: Juho Hämäläinen <juho.hamalainen@tieto.com>
Co-authored-by: Petri Takalokastari <petri.takalokastari@oss.tieto.com>
Co-authored-by: Jarko Poutiainen <Jarko.Poutiainen@oss.tieto.com>
Co-authored-by: Tommi Kenakkala <tommi.kenakkala@oss.tieto.com>
Co-authored-by: Miia Leinonen <miia.leinonen@oss.tieto.com>
Co-authored-by: Martti Piirainen <martti.piirainen@canonical.com>
Co-authored-by: You-Sheng Yang <vicamo.yang@canonical.com>
When a call is waitng, CCWA event is sent and call object
in state WAITING is created. on ReleaseAndAnswer it is
promoted to INCOMING and later to ACTIVE.
iPhones send an extra CCWA event when active call is ended.
This extra event is creating a second call object in state
WAITING. It is not possible to have two WAITING calls, but
previously waiting call was already promoted to INCOMING.
For a brief time we have two calls from the same number,
one INCOMING and one WAITING. Later WAITING one is removed.
As we cannot have a waiting and incoming call at the same
time, ignore CCWA when there is already an INCOMING call.
< \r\n+CIEV: 3,3\r\n
< \r\n+CIEV: 2,1\r\n
< \r\n+CIEV: 3,0\r\n
< \r\n+CCWA: "01234567890",129,1,"Me"\r\n
< \r\n+CIEV: 3,1\r\n
> AT+CLCC\r
< \r\n+CLCC: 1,0,0,0,0,"09876543210",129,"Me"\r\n
< \r\n+CLCC: 2,1,5,0,0,"01234567890",129,"Me"\r\n
< \r\nOK\r\n
< \r\n+CIEV: 2,0\r\n
< \r\n+CCWA: "01234567890",129,1,"Me"\r\n
< \r\n+CIEV: 2,1\r\n
< \r\n+CIEV: 3,0\r\n
> AT+CLCC\r
< \r\n+CLCC: 2,1,0,0,0,"01234567890",129,"Me"\r\n
< \r\nOK\r\n
It is possible for the phone to accept Dial request
but not actually dial. This leaves a voicecall object
in state 'dialling' that cannot be removed.
Proposed workaround is to trigger AT+CLCC when an error
is returned for Hangup. As the call is not on the list,
this would remove this hanging object and signal CallRemoved.
Windows Phone trace with this fix:
ofonod[273]: > ATD1;\r
ofonod[273]: < \r\nOK\r\n
ofonod[273]: src/voicecall.c:dial_handle_result() Registering new call: 1
ofonod[273]: < \r\n+CIEV: 5,4\r\n
ofonod[273]: src/network.c:ofono_netreg_strength_notify() strength 80
ofonod[273]: > AT+CHUP\r
ofonod[273]: < \r\nERROR\r\n
ofonod[273]: src/voicecall.c:generic_callback() command failed with error: Unknown error type
ofonod[273]: > AT+CLCC\r
ofonod[273]: < \r\nOK\r\n
ofonod[273]: src/voicecall.c:ofono_voicecall_disconnected() Got disconnection event for id: 1, reason: 2
If there is more then one active or held call, we are in mpty calls.
We won't get indicator update if any of them is released by CHLD=1x.
So we have to poll it.
A periodic CLCC polling is started when there is an ongoing multiparty
call and a new call appears in the system. A simple way to reproduce
the crashing scenario is:
1. Place a call.
2. Place a second call.
3. Create a multiparty call with both calls.
4. Place a third call (incoming or outgoing does not matter).
5. Disconnect HFP from the modem.
Within the function ciev_callheld_notify, the AT+CLCC command is also
invoked, thus a new cyclic CLCC polling is started, and it overwrites
the timer resource identifier stored in voicecall_data.clcc_source.
This means that there are several timers doing the CLCC polling, but
only one of those is under control, i.e. it can be removed through its
source identifier, hence a timer source leak.
This has a fatal consequence when the HFP modem is disconnected. The
function hfp_voicecall_remove stops the timer that is under control
before freeing the voicecall_data struct. However there are other timers
that are still active and will execute its handler poll_clcc afterwards.
Inside poll_clcc the driver_data is accessed, which is already NULL.
A solution for this is to avoid starting a CLCC polling if there is
already one active, i.e. clcc_source is not 0. By doing this the
uncontrolled timers will not cycle forever.
According to the standard "3GPP 27.007 v6.8.0" Appendix C.2.11,
when sending multiple DTMF characters, these must go in individual
+VTS commands for each tone. This adopts the AT modem approach.
Before: AT+VTS=1234\r
After: AT+VTS=1;+VTS=2;+VTS=3;+VTS=4\r
The affected call types for +CHUP were set to only ACTIVE calls.
Instead the affected set should include INCOMING, DIALING, ALERTING and
ACTIVE calls.
Thanks to Ionut Dediu for the diagnosing and reporting this issue.
The SIM900 module from SIMCOM does have a AT+CGDATA command.
However, it is not possible to make a ppp connection when CGDATA
has been used to bring up the gprs context.
This patch adds a quirk that uses the alternative ATD*99***<cid>#
command instead.
Before, the AT+BAC command was being sent with fixed information,
now we send the command (that inform the AG of the codecs supported by
the HF) with the codecs supported by the registered Handsfree Audio
Agent.
This patch fixes segmentation fault when the network registration
watch is called without being initialized. CIEV GAtChat callback can
be called before ofono_netreg_register().
==15101== Invalid read of size 8
==15101== at 0x492B56: ofono_netreg_register (network.c:2073)
==15101== by 0x47245E: hfp_netreg_probe (network-registration.c:311)
==15101== by 0x492A8D: ofono_netreg_create (network.c:1881)
==15101== by 0x4849D5: hfp_pre_sim (hfp_hf_bluez5.c:288)
==15101== by 0x48C486: ofono_modem_set_powered (modem.c:1194)
==15101== by 0x484E9D: slc_established (hfp_hf_bluez5.c:85)
==15101== by 0x4702AD: chld_cb (slc.c:147)
==15101== by 0x440457: at_chat_finish_command (gatchat.c:461)
==15101== by 0x44109F: new_bytes (gatchat.c:532)
==15101== by 0x4433B7: received_data (gatio.c:122)
==15101== by 0x3CBAA47824: g_main_context_dispatch (gmain.c:2539)
==15101== by 0x3CBAA47B57: g_main_context_iterate.isra.23
(gmain.c:3146)
==15101== Address 0x18 is not stack'd, malloc'd or (recently) free'd
Some phones do not send the corresponding call state update (+CIEV)
after a successful release-and-swap operation (AT+CHLD=1).
This has been observed with a Nokia 500, while testing ReleaseAndSwap()
while an active and a held call exist:
ofonod[20414]: > AT+CLCC\r
ofonod[20414]: < \r\n+CLCC: 1,0,1,0,0,"<number1>",145\r\n
ofonod[20414]: < \r\n+CLCC: 2,0,0,0,0,"<number2>",145\r\n
ofonod[20414]: < \r\nOK\r\n
ofonod[20414]: > AT+CHLD=1\r
ofonod[20414]: < \r\nOK\r\n
After this, no +CIEV is received, but the call has been hung up.
The proposed approach to solve this consists of using AT+CLCC, unless
a call release has been received within a specific time period.
The result fixes the problem as can be seen below:
ofonod[20847]: < \r\n+CLCC: 1,0,1,0,0,"<number1>",145\r\n
ofonod[20847]: < \r\n+CLCC: 2,0,0,0,0,"<number2>",145\r\n
ofonod[20847]: < \r\nOK\r\n
ofonod[20847]: > AT+CHLD=1\r
ofonod[20847]: < \r\nOK\r\n
ofonod[20847]: > AT+CLCC\r
ofonod[20847]: < \r\n+CLCC: 1,0,0,0,0,"<number1>",145\r\n
ofonod[20847]: < \r\nOK\r\n
ofonod[20847]: < \r\n+CIEV: 5,2\r\n
ofonod[20847]: < \r\n+CIEV: 5,0\r\n
While processing the result of AT+CLCC, process the differences in a way
that disconnections are reported first, then call state changes and
finally new calls.
The goal is to avoid unnecessary transitional states such as two active
calls existing at the same time.
Right now, only the mandatory CVSD codec is supported. The mSBC
mandatory codec is "temporarily" not supported.
The spec alows this, HFP 1.6 Spec Section 4.34.1 page 92: "If wide band
speech is supported then the mandatory codec (mSBC) shall be included
unless it is temporarily unavailable."
Especially for Telit HE910 it is not enough to wait for
entering a PIN code.
If we do not wait for #QSS: 3, subsequent commands,
like +CMER will report SIM BUSY and the network registration
atom will be removed as a consequence.
If device probe and removal happen in short succession, it's possible
that the idle handler registered in the probe function doesn't run before
the device is removed. In this case, the idle handler needs to be
unregistered so that it does not run and try to access the data that's
destroyed during the removal.
We might have mis-interpreted how 27.007 intends for CBS to work. After
studying the implementation notes of the IMC 6260 modem, the spec intent
made a little bit more sense.
During STK Set Up Call, we have modem-originated calls that do not go
through the core 'Dial' method. Make sure the calls are still detected
in this case.
Encountered a problem of CME ERROR 14: SIM busy on Alcatel and Huawei modem.
The Huawei modem has a ^SIMST unsollicited sim state indication, but not all
Huawei modems support this.
So poll the SIM state, as was already done for ZTE modems.
The Wavecom Q2XXX support broke in commit 72ce19bf3e.
This is because at_cpin_cb called decode_at_error with final and not
with OK. This lead to an error being set in the error variable and the
new code returns early when an error is set.
The addition of the terminator in at_sim_probe for Wavecom broke in
git commit ac524be99f because
terminators can not be added on cloned chats.
Move the addition of the terminator from the atmodem to the wavecom
plugin. Use the same terminator for Q2XXX and the normal Wavecom
class. The WAVECOM terminator has been tested on a Q2XXX modem.
Apply the CPIN quirk for both WAVECOM and WAVECOM_Q2XXX inside the
sim.c file. Introduce needs_wavecom_sim_quirk to handle it for
WAVECOM and WAVECOM_Q2XXX.
The existing wavecom driver in tree slightly differs from these
modems. Thus, it doesn't work work with them. We (the osmocom
team) use these Wavecom Q2403/Q2686 modems in our testbed.