[PATCH_v4 0/5] Private network request to ConnMan
by Guillaume Zajac
Hi,
Changelog from v3 is:
- Add private-network source/include
- ConnMan plugin is independant from emulator
- Each application that need VPN will pass a callback as argument
when private network is requested. This callback will contain the
private network settings.
Guillaume Zajac (5):
gatppp: Add new contructor to use external fd
private-network: add callback typedef drivers and settings
private-network: add request/release functions and new feature to
Makefile.am
emulator: add request/release private network calls
connman: add plugin in oFono to request request/release private
network
Makefile.am | 10 +-
gatchat/gatppp.c | 33 +++++-
gatchat/gatppp.h | 1 +
gatchat/ppp.h | 2 +-
gatchat/ppp_net.c | 40 ++++---
include/private-network.h | 59 +++++++++
plugins/connman.c | 297 +++++++++++++++++++++++++++++++++++++++++++++
src/emulator.c | 49 ++++++--
src/ofono.h | 6 +
src/private-network.c | 89 ++++++++++++++
10 files changed, 556 insertions(+), 30 deletions(-)
create mode 100644 include/private-network.h
create mode 100644 plugins/connman.c
create mode 100644 src/private-network.c
2 months, 3 weeks
ofono fails to compile on gcc-6.3
by Pavel Machek
Hi!
I'm getting this:
CC drivers/rilmodem/network-registration.o
drivers/rilmodem/network-registration.c:40:32: error: unknown option
after ‘#pragma GCC diagnostic’ kind [-Werror=pragmas]
#pragma GCC diagnostic ignored "-Wrestrict"
cc1: error: unrecognized command line option ‘-Wno-format-truncation’
[-Werror]
cc1: all warnings being treated as errors
I commented out #pragma, and this allows compilation to
continue... until I hit same issue in
drivers/rilmodem/call-forwarding.c:41:32:
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
2 years, 8 months
Re: Motorola motmdm support
by Pavel Machek
Hi!
> Oh, I think I forgot to answer your question regarding PM,
> there's nothing that the user space needs to except to avoid
> polling the /dev/motmdm* devices unnecessarily. And to type
> AT+SCRN=0 on /dev/motmdm1 when no notifications for signal
> strength and network status are needed.
Is it possible that epoll() does not work properly with /dev/motmdm*?
I am debugging weird problems with ofonod, and that would be an
explanation...
epoll.poll() should be returning list of file descriptors and if they
are ready. And it seems to work for ttyUSB4 but not for motmdm.
Hmm. And motmdm_cdev_poll() lacks EPOLLOUT() support, right? That
could explain things...
Best regards,
Pavel
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("/dev/ttyUSB4", "r+")
>>> f.write("AT\r\n")
>>>
>>> import select
>>> epoll = select.epoll()
>>> epoll.register(1, select.EPOLLOUT)
>>> epoll.register(f.fileno(), select.EPOLLOUT | select.EPOLLIN)
>>> epoll.poll(1)
[(1, 4), (3, 5)]
>>> select.EPOLLOUT
4
>>> select.EPOLLIN
1
>>> f = open("/dev/motmdm1", "r+")
>>> #f = open("/dev/ttyUSB4", "r+")
... f.write("AT\r\n")
>>>
>>> import select
>>> epoll = select.epoll()
>>> epoll.register(1, select.EPOLLOUT)
>>> epoll.register(f.fileno(), select.EPOLLOUT | select.EPOLLIN)
>>> epoll.poll(1)
[(1, 4)]
>>>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
2 years, 9 months
Motorola motmdm support
by Pavel Machek
Hi!
Motorola phones use "interesting" setup.
There's qmi and "normal" (but very buggy) AT interface on
them. Unfortunately that uses USB and uses too much power (which is a
problem on phone).
Plus there's /dev/motmdm1, motmdm3 and motmdm9, multiplexed over
serial line.
It uses subset of AT commands (good) with slightly modified
protocol... it says ":OK" instead of "OK" and puts ~ before
unsolicited messages.
Other major difference is that commands need to be sent to the right
device. It seems motmdm1 is for status and call control, and motmdm9
is for incoming sms.
I guess that right way to do this is to introduce
drivers/motorolamodem (or can we just have drivers/motorola?).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
2 years, 9 months
Re: Motorola motmdm support
by Denis Kenzior
Hi Tony,
>> How are you handling data connections? PPP? Or is there some other protocol
>> to transfer packets back and forth?
>
> All the data connections in this case are done using QMI over USB.
>
> And that probably explains why I have not seen any data related
> stuff on ts 27.010.
Ew. So is everything related to packet services is running over QMI?
When Pavel explained that he wanted to use the weird squiggly AT
commands, I assumed you wanted to run the packet services over AT as well.
>
>>>> - GNSS/GPS is intended to be handled via oFono LocationReporting API. I
>>>> would recommend integrating this as intended...
>>>
>>> We have a standard kernel GNSS API now :) And we have /dev/gnss0
>>> already working for droid 4.
>>
>> That's great. But I think my recommendation still stands. You want GPS
>> state to be synchronized with the overall modem state, etc...
>
> Hmm sounds like ofono would benefit from using /dev/gnss0 in the
> long run though. I guess the situation is similar to having
> multiple computer mouse drivers earlier with their own interfaces
> vs standard /dev/input :)
Yep, agreed. I already tried to nudge Pavel to propose something.
>
>> I believe the utilities you mention should be good enough to decode the
>> basics. I think someone has even tested these on a real network at some
>> point. But the people working on CDMA have not contributed since ~2011, so
>> I have no idea about the state of that code. I was considering removing it
>> given that CDMA is essentially defunct (or will be in a few years).
>
> OK, sounds like we might need the CDMA PDU features for few more
> years though.
That's fine, as long as someone is actually using these. Right now it
is unmaintained code.
>
> Oh, I think I forgot to answer your question regarding PM,
> there's nothing that the user space needs to except to avoid
> polling the /dev/motmdm* devices unnecessarily. And to type
> AT+SCRN=0 on /dev/motmdm1 when no notifications for signal
> strength and network status are needed.
>
Right, but since /dev/motmdm1 would in theory belong exclusively to
oFono, you probably still need some way of sending the screen 'off'
command. So in effect you're integrating power management with the
telephony stack.
Regards,
-Denis
2 years, 9 months
Re: Motorola motmdm support
by Denis Kenzior
Hi Tony,
On 12/30/2018 02:24 PM, Tony Lindgren wrote:
> * Denis Kenzior <denkenz(a)gmail.com> [181230 19:32]:
>> You still need someone to send AT+CMUX, no? And you most likely need to
>> integrate power management into the telephony stack anyway. As I mentioned,
>> we had a driver like this that worked just fine. oFono ended up using a
>> user space MUX since most of the quality of life improvements to n_gsm came
>> in much later. If I was writing a new MUXed driver these days, I'd
>> seriously consider using GSMIOC_SETCONF and GSMIOC_ENABLE_NET.
>
> No need to type AT+CMUX or anything, things start in ts 27.010
> mode from the start for the hardware. Then the serdev driver
> layer handles doing GSMIOC_SETCONF.
Gotcha. That makes things a bit easier.
>
> I have not played with GSMIOC_ENABLE_NET, I thought that needed
> support on the modem side as well, but maybe not?
>
It requires the modem to support Raw IP. Many (most?) AT command based
modems do these days, no idea about your hardware.
> Would GSMIOC_ENABLE_NET make things easier from ofono
> point of view?
Depends on your definition of easier. The real reason for
GSMIOC_ENABLE_NET is speed/efficiency. In a typical 27.010 / 27.007
compliant modem you'd setup N logical AT command channels where N = 1
(minimum, but can be more if you want) + max number of active contexts.
Typically modems support 3+ of these. Once a context is activated,
you'd switch the channel into data mode via AT+CGDATA (e.g. for PPP or
raw IP) and start shoving your network packets on that channel in the
format chosen.
How are you handling data connections? PPP? Or is there some other
protocol to transfer packets back and forth?
>> - GNSS/GPS is intended to be handled via oFono LocationReporting API. I
>> would recommend integrating this as intended...
>
> We have a standard kernel GNSS API now :) And we have /dev/gnss0
> already working for droid 4.
That's great. But I think my recommendation still stands. You want GPS
state to be synchronized with the overall modem state, etc...
>
>> There's no real functional CDMA support in oFono anyhow. Given that most
>> CDMA networks are about to be switched off, I don't know why you would
>> bother?
>
> Hmm right, good point. Anyways that's how the SMS gets sent and
> received in the US for droid 4 currently.. The file I was looking at
> is src/cdma-sms.c and the only thing to do there is the PDU coding
> and encoding.
I believe the utilities you mention should be good enough to decode the
basics. I think someone has even tested these on a real network at some
point. But the people working on CDMA have not contributed since ~2011,
so I have no idea about the state of that code. I was considering
removing it given that CDMA is essentially defunct (or will be in a few
years).
Regards,
-Denis
2 years, 9 months
Re: Motorola motmdm support
by Denis Kenzior
Hi Tony,
>> It might make your job easier if the oFono driver itself invoked the
>> necessary magic to setup the multiplexer and handed off the devices as
>> needed. We used to have a driver like this, but not sure if it ever made it
>> upstream.
>
> Playing with ldattach and user space handling earlier this year did
> not work out good.. It needed app specific handling for the Motorola
> custom layer on top of ts 27.010, custom handling for all the devices
> such as GNSS and audio mixer, and did not work well with device
> specific power management. So let's not go back to that :)
You still need someone to send AT+CMUX, no? And you most likely need to
integrate power management into the telephony stack anyway. As I
mentioned, we had a driver like this that worked just fine. oFono ended
up using a user space MUX since most of the quality of life improvements
to n_gsm came in much later. If I was writing a new MUXed driver these
days, I'd seriously consider using GSMIOC_SETCONF and GSMIOC_ENABLE_NET.
How does the audio mixer handling work? Just some AT commands to setup
the mixing parameters, or something more involved?
Some other things to consider:
- oFono expects / is designed to expect exclusive access to all the tty
ports
- GNSS/GPS is intended to be handled via oFono LocationReporting API. I
would recommend integrating this as intended...
>
>>> One more question: I guess I'll need to implement this... Is there
>>> another example of driver doing AT commands but on multiple file
>>> descriptors? I could really use something to look at as a template..
>>
>> Any driver for a USB based device would be setup this way. Each AT port is
>> a separate file, e.g. ttyUSB1, ttyACM2, etc. The discovery is done via
>> udev. See plugins/mbm.c or plugins/ublox.c or plugins/telit.c, etc.
>>
>> Assuming you don't want to setup the multiplexer in oFono, then the only
>> tricky part is the port setup. udevng.c setup_serial_modem() assumes a
>> single port, so you might need to add some extra logic to setup the ports
>> via udev rules.
>
> We have network status data at /dev/motmdm1, outgoing SMS PDU device at
> /dev/motmdm3, incoming SMS PDU device at /dev/motmdm9 and so on for each
> ts 27.010 channel. At least incoming and outgoing SMS PDU devices could
> be considered as separate modems if that makes things easier?
No, that just makes things more difficult.
>
>> Alternatively, simply use a config file specific to your driver. See for
>> example how plugins/phonesim.c does this.
>>
>> Or, if it is an extremely platform specific driver, then just hardcode it.
>> E.g. like plugins/calypso.c, which only works for the Freerunner.
>
> Just adding one more thing to consider: Looks like the modem handling for
> SMS PDU's needs to be specific to the nework. First the network needs to
> be detected, and then the GSM or CDMA handlers need to be used for sending
> and receiving SMS. After that things should get standard.. Looks like
> ofono has parsing for the different type SMS PDUs in src/*sms*.c :)
>
There's no real functional CDMA support in oFono anyhow. Given that
most CDMA networks are about to be switched off, I don't know why you
would bother?
Regards,
-Denis
2 years, 9 months
Re: GPIO power management
by Tarmo Kuuse
Hi Martin,
>>> I previously submitted pacthes[1] for the Quectel M95 modem, and now
>>> finally have the time needed to address the review comments.
>>>
>>> In the meantime, my hardware has changed (modem chip remains the same
>>> though), and so I would like to add more generic power management the
>>> ofono driver.
>>>
>>> I would assume that I cannot be the first with the urge to control
>>> modem power using GPIOs (found one example in
>>> ofono/plugins/nokia-gpio.c), so
>>
>> Maybe not the first, but nobody has brought this up for oh ~8 years or
>> so. So might as well treat yourself as the first ;)
>
> I see.. Maybe I will not be the last then :)
You are certainly not the last. I have a Beaglebone-derived device with
a slightly wobbly Quectel UC20 connected to a slightly wobbly USB host
controller. As a preventative measure I plan to toggle reset of both the
USB controller and GSM module before a dial-up session is (re)started.
>>> it might make sense to add GPIO helper in a common object, and use
>>> libgpiod in there?
>>
>> We will not be adding any further dependencies on GLib based libraries
>> for oFono as GLib use is going to be deprecated over time (in favor of
>> ell). This is especially true for a small library like libgpiod.
>
> I don't think libgpiod i GLib based:
>
> ldd /usr/lib/libgpiod.so
> linux-vdso.so.1 (0x00007ffe90977000)
> libc.so.6 => /usr/lib/libc.so.6 (0x00007f325b3d4000)
> /usr/lib64/ld-linux-x86-64.so.2 (0x00007f325b5b4000)
>
>> So this has to be done either inside oFono itself or preferably as a set
>> of class(es) inside ell.
>
> As long as it is only a matter of setting a single GPIO on/off, then I
> think a helper in common/gpio.{c,h} should be enough - something like
> this from my little test program:
>
> static bool gpio_set(uint32_t chip, uint32_t line, uint8_t value)
> {
> struct gpiohandle_request req = {0};
> char path[] = "/dev/gpiochipXX";
> int ret, fd;
>
> snprintf(path, sizeof(path), "/dev/gpiochip%u", chip);
> fd = open(path, O_RDWR | O_CLOEXEC);
> if (fd < 0) {
> error(0, errno, "open: %s", path);
> return false;
> }
>
> req.lineoffsets[0] = line;
> req.lines = 1;
> req.flags = GPIOHANDLE_REQUEST_OUTPUT;
> req.default_values[0] = !!value;
> strncpy(req.consumer_label, "ofono", sizeof(req.consumer_label));
>
> ret = ioctl(fd, GPIO_GET_LINEHANDLE_IOCTL, &req);
> if (ret < 0) {
> error(0, errno, "ioctl");
> return false;
> }
>
> return true;
> }
Do I assume correctly that this is a work in progress? I'm going to hack
out a prototype to test the wobbliness countermeasures, but I'd like to
have a rough idea of how temporary my hack would end up being.
>>> If that would be acceptable, a way to configure such GPIO
>>> numbers/names is needed. Should this be done with an OFONO_CONFIG env
>>> attribute in the udev rules?
>>
>> That is ultimately up to the driver. Serial devices have to rely on
>> udev rules or configuration files, so either should be fine.
>
> udev rules it is then
Are the Ofono udev rules documented anywhere? I can see two .rules files
in the plugins directory, but they're a bit cryptic.
--
Kind regards,
Tarmo
2 years, 10 months
[PATCH] sim: Sim PIN1 cache upon modem reset/crash
by Nandini Rebello
Adding SIM PIN caching feature to oFono. oFono now caches the SIM PIN1 type
against the ICCID throughout its lifetime in a link list and enters
implicitly upon modem reset/crash.
Handles cases of incorrect pin and sim pin changed externally.
Adding to all modems by default.
---
src/sim.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 114 insertions(+)
diff --git a/src/sim.c b/src/sim.c
index 129ff5d..28d9a00 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -141,6 +141,11 @@ struct ofono_sim {
bool wait_initialized : 1;
};
+struct cached_pin {
+ char *id;
+ char *pin;
+};
+
struct msisdn_set_request {
struct ofono_sim *sim;
int pending;
@@ -176,6 +181,8 @@ static void sim_own_numbers_update(struct ofono_sim *sim);
static GSList *g_drivers = NULL;
+static GSList *cached_pins = NULL;
+
static const char *sim_passwd_name(enum ofono_sim_password_type type)
{
return passwd_name[type];
@@ -473,6 +480,75 @@ done:
return reply;
}
+static struct cached_pin *pin_cache_lookup(const char *iccid)
+{
+ struct cached_pin *c;
+ GSList *l;
+
+ for (l = cached_pins; l; l = l->next) {
+ c = l->data;
+
+ if (g_strcmp0(iccid, c->id) == 0)
+ return c;
+ }
+
+ return NULL;
+}
+
+static gboolean pin_cache_update(const char *iccid, const char *pin)
+{
+ struct cached_pin *pin_cached = pin_cache_lookup(iccid);
+ struct cached_pin *cpins;
+
+ if (pin_cached != NULL) {
+ g_free(pin_cached->pin);
+ pin_cached->pin = g_strdup(pin);
+ return TRUE;
+ }
+
+ cpins = g_new0(struct cached_pin, 1);
+
+ if (cpins == NULL)
+ return FALSE;
+
+ cpins->id = g_strdup(iccid);
+ cpins->pin = g_strdup(pin);
+ cached_pins = g_slist_prepend(cached_pins, cpins);
+
+ return TRUE;
+}
+
+static void pin_cache_remove(const char *iccid)
+{
+ struct cached_pin *pin_cached = pin_cache_lookup(iccid);
+
+ if (pin_cached == NULL)
+ return;
+
+ cached_pins = g_slist_remove(cached_pins, pin_cached);
+}
+
+static void pin_cache_enter_cb(const struct ofono_error *error, void *data)
+{
+ struct ofono_sim *sim = data;
+
+ /* If PIN entry fails, then remove cached PIN*/
+ if (sim->initialized || error->type != OFONO_ERROR_TYPE_NO_ERROR) {
+ pin_cache_remove(sim->iccid);
+ goto recheck;
+ }
+
+ if (sim->pin_type == OFONO_SIM_PASSWORD_SIM_PIN ||
+ sim->pin_type == OFONO_SIM_PASSWORD_SIM_PUK) {
+ sim->wait_initialized = true;
+ DBG("Waiting for ofono_sim_initialized_notify");
+ return;
+ }
+
+recheck:
+ __ofono_sim_recheck_pin(sim);
+}
+
static void sim_pin_retries_query_cb(const struct ofono_error *error,
int retries[OFONO_SIM_PASSWORD_INVALID],
void *data)
@@ -681,6 +757,13 @@ static void sim_locked_cb(struct ofono_sim *sim, gboolean locked)
OFONO_SIM_MANAGER_INTERFACE,
"LockedPins", DBUS_TYPE_STRING,
&locked_pins);
+
+ /*Cache pin only for SIM PIN type*/
+ if (g_strcmp0(typestr, "pin") == 0) {
+ if (!pin_cache_update(sim->iccid, pin))
+ ofono_error("Failed to cache PIN.");
+ }
+
g_strfreev(locked_pins);
sim_pin_retries_check(sim);
@@ -776,6 +859,14 @@ static DBusMessage *sim_unlock_pin(DBusConnection *conn, DBusMessage *msg,
static void sim_change_pin_cb(const struct ofono_error *error, void *data)
{
struct ofono_sim *sim = data;
+ const char *typestr;
+ const char *old;
+ const char *new;
+
+ dbus_message_get_args(sim->pending, NULL, DBUS_TYPE_STRING, &typestr,
+ DBUS_TYPE_STRING, &old,
+ DBUS_TYPE_STRING, &new,
+ DBUS_TYPE_INVALID);
if (error->type != OFONO_ERROR_TYPE_NO_ERROR) {
__ofono_dbus_pending_reply(&sim->pending,
@@ -786,6 +877,12 @@ static void sim_change_pin_cb(const struct ofono_error *error, void *data)
return;
}
+ /*Cache pin only for SIM PIN type*/
+ if (g_strcmp0(typestr, "pin") == 0) {
+ if (!pin_cache_update(sim->iccid, new))
+ ofono_error("Failed to cache PIN.");
+ }
+
__ofono_dbus_pending_reply(&sim->pending,
dbus_message_new_method_return(sim->pending));
@@ -837,8 +934,14 @@ static DBusMessage *sim_change_pin(DBusConnection *conn, DBusMessage *msg,
static void sim_enter_pin_cb(const struct ofono_error *error, void *data)
{
struct ofono_sim *sim = data;
+ const char *typestr;
+ const char *pin;
DBusMessage *reply;
+ dbus_message_get_args(sim->pending, NULL, DBUS_TYPE_STRING, &typestr,
+ DBUS_TYPE_STRING, &pin,
+ DBUS_TYPE_INVALID);
+
if (error->type != OFONO_ERROR_TYPE_NO_ERROR)
reply = __ofono_error_failed(sim->pending);
else
@@ -850,6 +953,12 @@ static void sim_enter_pin_cb(const struct ofono_error *error, void *data)
if (sim->initialized || error->type != OFONO_ERROR_TYPE_NO_ERROR)
goto recheck;
+ /*Cache pin only for SIM PIN type*/
+ if (g_strcmp0(typestr, "pin") == 0) {
+ if (!pin_cache_update(sim->iccid, pin))
+ ofono_error("Failed to cache PIN.");
+ }
+
if (sim->pin_type == OFONO_SIM_PASSWORD_SIM_PIN ||
sim->pin_type == OFONO_SIM_PASSWORD_SIM_PUK) {
sim->wait_initialized = true;
@@ -3023,6 +3132,7 @@ static void sim_pin_query_cb(const struct ofono_error *error,
struct ofono_sim *sim = data;
DBusConnection *conn = ofono_dbus_get_connection();
const char *path = __ofono_atom_get_path(sim->atom);
+ struct cached_pin *cpins = pin_cache_lookup(sim->iccid);
const char *pin_name;
char **locked_pins;
gboolean lock_changed;
@@ -3067,6 +3177,10 @@ static void sim_pin_query_cb(const struct ofono_error *error,
&pin_name);
}
+ if (g_strcmp0(pin_name, "pin") == 0 && cpins != NULL)
+ sim->driver->send_passwd(sim, cpins->pin,
+ pin_cache_enter_cb, sim);
+
switch (pin_type) {
case OFONO_SIM_PASSWORD_NONE:
case OFONO_SIM_PASSWORD_SIM_PIN2:
--
2.7.4
2 years, 10 months
[PATCH 2/2] xmm7modem: modified ofono.conf for coex agent
by Antara Borwankar
Added coex agent interface to ofono.conf
---
src/ofono.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/ofono.conf b/src/ofono.conf
index 61e0bde..45cb15c 100644
--- a/src/ofono.conf
+++ b/src/ofono.conf
@@ -16,6 +16,7 @@
<allow send_interface="org.ofono.PositioningRequestAgent"/>
<allow send_interface="org.ofono.HandsfreeAudioAgent"/>
<allow send_interface="org.ofono.NetworkMonitorAgent"/>
+ <allow send_interface="org.ofono.intel.LteCoexistenceAgent"/>
</policy>
<policy at_console="true">
--
1.9.1
2 years, 10 months
