allowed-apns plugin will try to uregister the AllowedAccessPoints
interface whenever the sim state changes, even when not registered.
This results in the (benign) error being printed inside
ofono_modem_remove_interface:
Interface org.ofono.AllowedAccessPoints not found on the interface_list
+XSIM:7 state as defined in xmm7560 functional AT specification
only indicates ready for attach.
+CPIN: READY is received after SIM is completely initialized.
Also indicating readiness of Phonebook and SMS. Hence moving the
creation of SMS and Phonebook atom to xmm7xxx_post_sim function.
+XSIM:4 PUK needed state was not handled. It must be handled
same as PIN needed state. Added handling of this case to
switch_sim_state_status function.
After unplugging a Huawei USB dongle, the 'atoms' in oFono are removed
via 'flush_atoms'. Every atom has a destruct function pointer, used as
destructor. This includes the gprs_context atom that is currently
active.
The function calls are:
flush_atoms -> destruct -> gprs_context_remove ->
at_gprs_context_remove -> modem_disconnect
Because the device is physically removed, the IO channel for the AT
port is gone. In 'at_gprs_context_remove', there is an attempt to
resume communication over that AT port, but that is not possible. This
is detected, and 'io_disconnect' (pointer to 'modem_disconnect') is
called. 'modem_disconnect' has the same atom and tries to remove it
again, so it calls the same destructor. This continues infinitely.
This patch moves the GPRS context removal so that it only happens if the
modem port could be re-opened successfully. If the port cannot be
re-opened (in the case of modem removal), the atom is already in the
process of being removed by the process kicked off in flush_atoms.
This fix is limited to Huawei devices and has been tested using the
following devices:
- E3531i-2
- E3372
- E3531s-2
- E369
- E1552
Use at_util_sim_state_query_new() to query the sim inserted state. Once
that returns, the locked state is queried by issuing a AT+CPIN? command.
If not locked, a timer is started to query the quectel init status of
the sim. Once the init status is ready, the sim atom is created, and the
modem is set to powered, and the sim is signaled both inserted, and
initialized.
If locked, the modem is set to powered, and the sim atom is created.
This allows users to enter the pin to unlock the sim. Once the sim is
unlocked, a +CPIN: READY indication is caught to query the quectel
init status. Once the init status is ready, the sim is signaled
initialized.
All the above is needed, because the modem indicated +CPIN: READY before
the sim is really ready. The only way to be certain, is to wait for the
quectel init status to be ready. Even signaling the sim inserted
prematurely can cause to modem to hang during the initial AT+CRSM
commands.
uBlox devices present their USB interfaces well before those interfaces
are ready to respond to any commands. The documentation says to monitor
the 'greeting text' to detect readiness, but this 'greeting text' is not
actually specified for any device other than the TOBY L4.
What seems to work is to probe the device with 'AT' commands until the
device responds, and then to wait an additional second before
proceeding. The TOBY L4 reliably sends its 'greeting text' (+AT: READY)
within this interval.
It would be more rigorous to actually wait for the 'READY' indication
for the TOBY L4, but that would require knowing the device model before
the device model is actually queried. This is doable via the USB
product ID, but overkill when the above heuristic seems to work
reliably.
Before this patch, the ublox plugin was trying to achieve something like
the above with the g_at_chat_set_wakeup_command() function, but that had
some issues:
i) it did not work reliably, in particular failing badly on the TOBY L4
with responses getting out of sync with commands
ii) it was an inappropriate use of the wakeup_command which is intended
for devices that may sleep when there is no communication during some
interval
This patch adds an init sequence that probes the device for readiness
before continuing with initialization.
Just reshuffling the code a bit and the 'disable' path can use the
close_devices() helper to finish up. This also prevents a bug should
the CFUN command fail to disable the modem whereby the 'aux' device
remains open but the 'modem' device has already been closed.
The code for closing all the modem devices and flagging the modem as
unpowered is repeated several times in the driver... this patch puts
this code into a common helper for readability.
The quectel M95 and MC60 modems are picky about when the sim is properly
initialized, so the logic to detect this needs to be in the quectel
plugin.
After doing basic initialization, a CPIN query is issued to detect sim
state.
If the sim is unlocked and ready, a timer is created to wait for the
modem state (AT+QINISTAT) to complete. At this point ofono is notified
about the initialized sim.
If the sim is locked, a listener for "+CPIN: READY" is set up to
know when a pin is entered. Once the indication is received, the timer
is set up as if the sim was unlocked from the beginning.
If the sim is busy/resetting, the CPIN query is issued again.
According to the manual, when using CMUX on the UC15, it outputs
unsolicited indications on port 2 (i.e. /dev/gsmtty2), so the quectel
plugin must use this when registering for such.
If the modem isn't powered on, the use of g_at_chat_set_wakeup_command()
makes ofono send out AT strings in an endless loop. Avoid this by using
g_at_chat_retry() in a timer instead.
The Quectel modems issues unsolicited strings in case of power related
events. The UC15 uses +QIND: for the events, while M95 and MC60 uses
descriptive strings. (UC15 also uses a string for normal power down).
Register listeners for these strings/codes. The handler emits an
appropriate dbus signal, and closes down the modem if needed.
The gprs-context does special casing on the quectel serial modem when
probing the supported layer 2 protocols, so pass the vendor id when
setting up the atoms.
Some uBlox modems support multiple, simultaneously active contexts. These
contexts are either bridged to the network interface or handled
transparently by the modem acting like a router.
The problem with this approach is that ofono and ofono clients (e.g.
mmsd) expect a dedicated _local_ network interface for each context.
As such, it doesn't make sense for ofono to set up the multiple gprs
contexts.
Some u-blox devices present a USB network class device for data and some
just switch to PPP on (one of) the communication channel(s). Whether
the atmodem or ubloxmodem gprs-context driver should be used depends on
whether or not the network interface is present; check this condition
directly when deciding which driver to us.
Some Quectel models supports different features such as GNSS or
different URC strings. Add a field in the quectel data structure to be
used when adding support for said features.
The Quectel M95 modem issues a "Call ready" notification when call and
phonebook are ready, so set up a listener for that.
The only way to know when sms is ready is to issue QINITSTAT queries.
Since sms is always ready after call and phonebook, the queries are
initiated after creating call/phonebook.
This adds support for configuring a gpio in udev to control the modem
power.
To enable gpio control, specify OFONO_QUECTEL_GPIO_CHIP and
OFONO_QUECTEL_GPIO_OFFSET in the udev environment, for example:
KERNEL=="ttymxc0", ENV{OFONO_DRIVER}="quectel", \
ENV{OFONO_QUECTEL_GPIO_CHIP}="gpiochip2", \
ENV{OFONO_QUECTEL_GPIO_OFFSET}="26"
Setup GSM 07.10 multiplexing using the kernel n_gsm line discpline
driver, and use the virtual tty devices as Aux and Modem channels.
The driver supports rts/cts on the underlying serial device. This is
enabled with OFONO_QUECTED_RTSCTS udev environment, e.g.:
KERNEL=="ttymxc0", ENV{OFONO_DRIVER}="quectel", \
ENV{OFONO_QUECTEL_RTSCTS}="on"