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"
According to the u-blox AT Commands Manual and my tests
the response prefix of AT+UUSBCONF is "+UUSBCONF:", including
a colon. The colon was missing in the code, causing next step
to parse a number to fail, since a colon is not a number.
In a recent patch vendor family was only set if the device
did not support USBCONF, but that resulted in drivers
being registered the "generic" vendor. That caused
for instance netreg to use incorrect cmer mode and fail
on TOBY-L210.
Trying to set the networking mode to "bridge" mode in the plugin is bogus
because the setting does not apply until after the device has been
reset. Instead, the current setting should be queried.
If a user wants to set the modem networking mode, the setting should be
made outside of ofono.
The gprs-context driver has already been adjusted to query the
networking mode and to set things up accordingly.
Depending on the transport used on the data connection we want either
the "atmodem" (PPP) driver or the "ubloxmodem". For the "ubloxmodem",
we want to pass the model data so this patch wrangles some parameters to
make sure that right driver and right variant data are passed.
ttyACM0 (USB interface 02) is reportedly unreliable (breaking DHCP setup)
so the recommended approach is to use ttyACM2 (USB interface 06)
exclusively.
Some aspects of a device are detectable at runtime, like the USB profile
detection that was added in a patch preceding this one. This patch
switches the driver over from creating a new "vendor id" for each
profile to just setting a flag. This is more easily extensible as we
detect other features of the modem.
Jonas Bonn
Martin Hundebøll
Denis Kenzior
Stefan Herbrechtsmeier
Antara Borwankar
Richard Röjfors