[PATCH 0/8] [RFC] Support for serial u-blox NB-IoT modems
by philippedeswert＠gmail.com
From: Philippe De Swert <philippe.deswert(a)digitalistgroup.com>
Hi,
Lately we have been trying to get a u-blox SARA-R410 and R412 to work with ofono.
We inspired ourselves on the existing u-blox driver and ran into some weird
issues (mostly issues with roaming sims). So it would be nice to get some feedback
on what we might have done wrong. We did have issues with ATD99
and would be very interested in knowing what we missed or did wrong there as we
needed to force it. We also found a small bug related to ppp and disconnects.
Thanks!
Philippe De Swert (7):
ublox-serial: add new plugin for u-blox
Makefile.am : include new u-blox serial modem driver
gprs-context : Force use of atd99
common: Add new NB-IoT technologies
Tommi Rekosuo (1):
gprs.h: Add ofono_gprs_get_netreg function
gprs.c: Add ofono_gprs_get_netreg function
atmodem/gprs.c: Add CEREG support
Fix gprs_netreg_update behaviour if PPP connection active
Makefile.am | 4 +
drivers/atmodem/gprs-context.c | 5 +-
drivers/atmodem/gprs.c | 60 ++++-
include/gprs.h | 1 +
plugins/ublox-serial.c | 393 +++++++++++++++++++++++++++++++++
plugins/udevng.c | 1 +
src/common.c | 4 +
src/common.h | 2 +
src/gprs.c | 29 ++-
9 files changed, 493 insertions(+), 6 deletions(-)
create mode 100644 plugins/ublox-serial.c
--
2.20.1
10 months, 2 weeks
[PATCH] xmm7modem: data channel setup for xmm7modem
by Antara Borwankar
Added the implementation required to setup data channel
in ifxmodem gprs-context driver for xmm7modem vendor
---
drivers/ifxmodem/gprs-context.c | 51 +++++++++++++++++++++++++++++++++++++----
1 file changed, 47 insertions(+), 4 deletions(-)
diff --git a/drivers/ifxmodem/gprs-context.c b/drivers/ifxmodem/gprs-context.c
index 7f3628b..b36740d 100644
--- a/drivers/ifxmodem/gprs-context.c
+++ b/drivers/ifxmodem/gprs-context.c
@@ -260,6 +260,36 @@ error:
failed_setup(gc, NULL, TRUE);
}
+static void cgdata_cb(gboolean ok, GAtResult *result, gpointer user_data)
+{
+ struct ofono_gprs_context *gc = user_data;
+ struct gprs_context_data *gcd = ofono_gprs_context_get_data(gc);
+
+ DBG("ok %d", ok);
+
+ if (!ok) {
+ ofono_error("Failed to establish session");
+ failed_setup(gc, result, TRUE);
+ return;
+ }
+
+ CALLBACK_WITH_SUCCESS(gcd->cb, gcd->cb_data);
+}
+
+static void get_datapath(struct ofono_modem *modem, const char *interface,
+ char* datapath)
+{
+ if (!datapath)
+ return;
+
+ if (!strcmp(interface, ofono_modem_get_string(modem, "NetworkInterface")))
+ sprintf(datapath, "%s0", ofono_modem_get_string(modem, "DataPath"));
+ else if (!strcmp(interface, ofono_modem_get_string(modem, "NetworkInterface2")))
+ sprintf(datapath, "%s1", ofono_modem_get_string(modem, "DataPath"));
+ else if (!strcmp(interface, ofono_modem_get_string(modem, "NetworkInterface3")))
+ sprintf(datapath, "%s2", ofono_modem_get_string(modem, "DataPath"));
+}
+
static void cgcontrdp_cb(gboolean ok, GAtResult *result, gpointer user_data)
{
struct ofono_gprs_context *gc = user_data;
@@ -269,8 +299,11 @@ static void cgcontrdp_cb(gboolean ok, GAtResult *result, gpointer user_data)
const char *laddrnetmask = NULL;
const char *gw = NULL;
- const char *interface;
const char *dns[3];
+ const char *ctrlpath;
+ char datapath[50];
+ char buf[100];
+ const char *interface;
DBG("ok %d", ok);
@@ -327,9 +360,10 @@ static void cgcontrdp_cb(gboolean ok, GAtResult *result, gpointer user_data)
DBG("DNS2: %s\n", gcd->dns2);
DBG("Gateway: %s\n", gcd->gateway);
- interface = ofono_modem_get_string(modem, "NetworkInterface");
+ ctrlpath = ofono_modem_get_string(modem, "CtrlPath");
+ interface = ofono_gprs_context_get_interface(gc);
+ get_datapath(modem, interface, datapath);
- ofono_gprs_context_set_interface(gc, interface);
ofono_gprs_context_set_ipv4_address(gc, gcd->address, TRUE);
if (gcd->netmask[0])
@@ -340,7 +374,16 @@ static void cgcontrdp_cb(gboolean ok, GAtResult *result, gpointer user_data)
ofono_gprs_context_set_ipv4_dns_servers(gc, dns);
- CALLBACK_WITH_SUCCESS(gcd->cb, gcd->cb_data);
+ sprintf(buf, "AT+XDATACHANNEL=1,1,\"%s\",\"%s\",2,%u", ctrlpath,
+ datapath, gcd->active_context);
+ g_at_chat_send(gcd->chat, buf, none_prefix, NULL, NULL, NULL);
+ sprintf(buf, "AT+CGDATA=\"M-RAW_IP\",%u", gcd->active_context);
+
+ if (g_at_chat_send(gcd->chat, buf, none_prefix, cgdata_cb,
+ gc, NULL) > 0)
+ return;
+
+ CALLBACK_WITH_FAILURE(gcd->cb, gcd->cb_data);
}
static void ifx_read_settings(struct ofono_gprs_context *gc)
--
1.9.1
10 months, 3 weeks
Test clients for ofono: rfone, Unicsy Demo
by Pavel Machek
Hi!
What ofono client are you using for development.. and for real usage
on a cellphone?
There are scripts in test/ which are suitable for early development,
but not really for real use or 'does everything work?' testing.
Anyway, I created some.
RFone -- https://gitlab.com/tui/tui/tree/master/rfone -- command line
tool written in Rust, by default monitors interesting events
(incomming call, sms, signal changes, registration changes), and has
command-line options for making/answering calls and sending sms. I'm
starting gtk support.
Unicsy Demo -- https://github.com/pavelmachek/unicsy_demo -- gtk phone
application meant for a phone, written in Python so a bit slow on
Nokia N900. But it has integrated phonebook, log of sms messages, is
fully graphical so possible to control from touchscreen, and actually
plays melody on incoming call. [Few GPL compatible melodies would
be good.] Quite basic, but should be useable.
Is there any other software I should look at?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
10 months, 4 weeks
ofono vs modemmanager
by JH
Hi,
I am new to ofono, we used to use modemmanager for 3G/4G modem in a
tiny embedded Linux device, I tried to search Internet for the
differences between ofono and modemmanager, but I could not find any.
What is the appealing reason I can justify to use ofnono over
modemmanager? Is it because connman?
Thank you.
Kind regards,
jupiter
11 months
Re: Test clients for ofono: rfone, Unicsy Demo
by Pavel Machek
Hi!
> > >SMS messages should be handled in similar way e-mails currently are --
> > >stored in maildir or mailbox formats, and accessible by common email
> > >clients. Access by two or more clients at the same time should be
> > >possible. Of course, special GUI client should be provided to work
> > >with SMS (using same maildir backend).
>
> That works nice based on my experiments over past few months :)
> The issues I've noticed so far are:
>
> 1. There's no subject line for sms, so getting threading to
> work needs some work with headers and some invented subject
> line
I agree it is quite good fit, but there are more issues. It would be
nice to be able to handle calls in similar way, for example... and
delivery reports. I believe it is best solution, but it is not _too_
great fit.
> 2. Starting any scripting language (other than perl?) can be
> super slow for sending sms for example.. Just starting ruby
> to run a script to send sms with droid4-sms-tools takes
> several seconds :) So yeah, sounds like rust should work
> well here assuming it does not have start-up time and memory
> bloatedness issues
Rust produces rather big binaries, but should be fast enough.
But... other scripting languages should not be too slow, either. Yes,
python is slow on N900 (but that's because I'm using gtk etc...) but
it is much better on Droid4. Maybe it is Ruby that is slow, or maybe
the pdu tools pull in a lot of code or something?
user@devuan:~$ time echo "3*3" | python
0.07user 0.03system 0.18 (0m0.183s) elapsed 57.43%CPU
user@devuan:~$ time echo "3*3" | python
0.07user 0.01system 0.08 (0m0.084s) elapsed 101.01%CPU
user@devuan:~$ time echo "3*3" | python3
0.14user 0.01system 0.17 (0m0.174s) elapsed 93.15%CPU
Ugh. Ok. Something is definitely wrong there. _Without_ background
load, python is actually slower:
user@devuan:~$ time echo "3*3" | python3
0.19user 0.02system 0.28 (0m0.280s) elapsed 77.84%CPU
yes > /dev/null gets it fast again:
user@devuan:~$ time echo "3*3" | python3
0.16user 0.00system 0.19 (0m0.193s) elapsed 84.19%CPU
Something wrong with power management?
Aha. But ruby is worse...:
user@devuan:~$ time echo "3*3" | ruby
0.46user 0.08system 1.09 (0m1.092s) elapsed 50.25%CPU
user@devuan:~$ time echo "3*3" | ruby
0.45user 0.06system 0.73 (0m0.731s) elapsed 70.22%CPU
> > >Simple text format should be supported for contacts -- probably as
> > >simple as number '\t' name. Many users will want something a bit more
> > >advanced, I'd prefer hierarchical structure offered by emacs "org"
> > >mode, allowing me to group contacts together. We should call external
> > >program to list contacts for us, allowing easy merging of contacts
> > >from multiple sources. "ph book" should provide the merged list.
>
> I've been using just using ~/aliases file with the following
> format with ".phone" in the alias:
>
> alias foo.phone Foo Bar <+1234567890>
So I already store my contacts in emacs org file... it looks like
this:
*** free Telecom
:PROPERTIES:
:VERSION: 3.0
:N: Telecom;free;;;
:PHONE: +420800123456
:END:
Advantage of org is that it is hierarchical. Anyway, I guess this
should be consumer of whatever phonebook format we give to it, as
different users may have different preferences there.
> > >There should be "ph primary" component responsible for calls and
> > >incoming SMSes -- mostly for actions not initiated by local user. On
> > >incoming events, it should play a melody. For calls, it should set up
> > >mixers, and display a window allowing user to manipulate volume,
> > >answer, reject and terminate the call. For incoming message,
> > >notification window should be displayed.
>
> Yeah I wonder if something like this already exists.. And I wonder
> if this component should also take care of setting up clock
> alarms as at jobs or something?
While I would like to have solution for alarms and calendar, I believe
that's separate project. I do have working alarm clock in tui/10f,
but...
> For reference, here's what I'm currently using for notifications
> (droid 4 specific):
>
> #!/bin/sh
>
> cat /dev/motmdm1 | while read -r line; do
> echo "${line}"
>
> if echo "${line}" | grep WAKEUP; then
> sudo rumble-test /dev/input/by-path/platform-vibrator-event 0xb000
> fi
> done
>
> Where rumble-test is Sebastian's tool for thw pwm-vibrator.
Hehe, quite clever :-).
> Or maybe any GUI you care to use :)
Yep, different people are starting to write more GUIs now. Hopefully
some of them survive, and hopefully we get some not needing 3d
acceleration.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
11 months
[PATCH 3/3] xmm7modem: data channel setup for xmm7modem
by Antara Borwankar
Added the implementation required to setup data channel in
ifxmodem gprs-context driver for xmm7modem vendor
---
drivers/ifxmodem/gprs-context.c | 43 +++++++++++++++++++++++++++++++++++++----
1 file changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/ifxmodem/gprs-context.c b/drivers/ifxmodem/gprs-context.c
index 7f3628b..278d507 100644
--- a/drivers/ifxmodem/gprs-context.c
+++ b/drivers/ifxmodem/gprs-context.c
@@ -260,6 +260,22 @@ error:
failed_setup(gc, NULL, TRUE);
}
+static void cgdata_cb(gboolean ok, GAtResult *result, gpointer user_data)
+{
+ struct ofono_gprs_context *gc = user_data;
+ struct gprs_context_data *gcd = ofono_gprs_context_get_data(gc);
+
+ DBG("ok %d", ok);
+
+ if (!ok) {
+ ofono_error("Failed to establish session");
+ failed_setup(gc, result, TRUE);
+ return;
+ }
+
+ CALLBACK_WITH_SUCCESS(gcd->cb, gcd->cb_data);
+}
+
static void cgcontrdp_cb(gboolean ok, GAtResult *result, gpointer user_data)
{
struct ofono_gprs_context *gc = user_data;
@@ -269,8 +285,11 @@ static void cgcontrdp_cb(gboolean ok, GAtResult *result, gpointer user_data)
const char *laddrnetmask = NULL;
const char *gw = NULL;
- const char *interface;
const char *dns[3];
+ const char *ctrlpath;
+ char *datapath;
+ char buf[100];
+ const char *interface;
DBG("ok %d", ok);
@@ -327,9 +346,13 @@ static void cgcontrdp_cb(gboolean ok, GAtResult *result, gpointer user_data)
DBG("DNS2: %s\n", gcd->dns2);
DBG("Gateway: %s\n", gcd->gateway);
- interface = ofono_modem_get_string(modem, "NetworkInterface");
+ ctrlpath = ofono_modem_get_string(modem, "CtrlPath");
+ interface = ofono_gprs_context_get_interface(gc);
+
+ sprintf(buf, "%s%c", ofono_modem_get_string(modem, "DataPath"),
+ interface[strlen(interface)-1]);
+ datapath = g_strdup(buf);
- ofono_gprs_context_set_interface(gc, interface);
ofono_gprs_context_set_ipv4_address(gc, gcd->address, TRUE);
if (gcd->netmask[0])
@@ -340,7 +363,19 @@ static void cgcontrdp_cb(gboolean ok, GAtResult *result, gpointer user_data)
ofono_gprs_context_set_ipv4_dns_servers(gc, dns);
- CALLBACK_WITH_SUCCESS(gcd->cb, gcd->cb_data);
+ sprintf(buf, "AT+XDATACHANNEL=1,1,\"%s\",\"%s\",2,%u", ctrlpath,
+ datapath, gcd->active_context);
+ g_at_chat_send(gcd->chat, buf, none_prefix, NULL, NULL, NULL);
+ sprintf(buf, "AT+CGDATA=\"M-RAW_IP\",%u", gcd->active_context);
+
+ if (g_at_chat_send(gcd->chat, buf, none_prefix, cgdata_cb,
+ gc, NULL) > 0) {
+ g_free(datapath);
+ return;
+ }
+
+ g_free(datapath);
+ CALLBACK_WITH_FAILURE(gcd->cb, gcd->cb_data);
}
static void ifx_read_settings(struct ofono_gprs_context *gc)
--
1.9.1
11 months, 1 week
[PATCH 1/3] gprs-context: adding get function for network interface
by Antara Borwankar
Added declaration of get function to get network interface
for gprs-context
---
include/gprs-context.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/gprs-context.h b/include/gprs-context.h
index 965cefc..ad0872f 100644
--- a/include/gprs-context.h
+++ b/include/gprs-context.h
@@ -92,6 +92,8 @@ void ofono_gprs_context_set_type(struct ofono_gprs_context *gc,
enum ofono_gprs_context_type ofono_gprs_context_get_type(
struct ofono_gprs_context *gc);
+const char *ofono_gprs_context_get_interface(struct ofono_gprs_context *gc);
+
void ofono_gprs_context_set_interface(struct ofono_gprs_context *gc,
const char *interface);
--
1.9.1
11 months, 1 week
Re: Test clients for ofono: rfone, Unicsy Demo
by Pavel Machek
Hi!
> > What ofono client are you using for development.. and for real usage
> > on a cellphone?
> >
> > There are scripts in test/ which are suitable for early development,
> > but not really for real use or 'does everything work?' testing.
> >
> > Anyway, I created some.
> >
> > RFone -- https://gitlab.com/tui/tui/tree/master/rfone -- command line
> > tool written in Rust, by default monitors interesting events
> > (incomming call, sms, signal changes, registration changes), and has
> > command-line options for making/answering calls and sending sms. I'm
> > starting gtk support.
>
> This looks like fun!
Yes, it is fun :-). But I'm a bit busy.
> > Is there any other software I should look at?
>
> I am also wondering about this. For Maemo Leste we also want a gtk or qt
> (likely gtk2 for now) ofono phone UI, and I was also not able to find
> much. Would like it to be written in C, C++ or Rust though (not Python
> for performance and ram/memory usage concerns).
>
> If we can agree on some general architectural/UI direction and goals I
> could try to help out. (In the end I probably want something that
> monitors ofono but is not shown all the time, as on Maemo Fremantle)
I agree that Python needs too much RAM; I tried with Vala, but I
believe Rust is really a better solution.
And yes, the long running stuff (ph monitor) should probably not
display window all the time, but work with the system tray to show the
signal. But I did not do too much investigation into that.
My design goals are described below. Help would be certainly welcome.
Best regards,
Pavel
# Goals
One day, this should turn into "Unicsy Phone", phone support that
integrates well with the rest of the Unix system. Phone functionality
should be available both from command-line and from simple
GUI. Important data should be stored in plain-text formats that are
easy to access with common software.
SMS messages should be handled in similar way e-mails currently are --
stored in maildir or mailbox formats, and accessible by common email
clients. Access by two or more clients at the same time should be
possible. Of course, special GUI client should be provided to work
with SMS (using same maildir backend).
Simple text format should be supported for contacts -- probably as
simple as number '\t' name. Many users will want something a bit more
advanced, I'd prefer hierarchical structure offered by emacs "org"
mode, allowing me to group contacts together. We should call external
program to list contacts for us, allowing easy merging of contacts
from multiple sources. "ph book" should provide the merged list.
# Design
Non-GUI component should be responsible for maintaining call log and
incoming SMSes. History plugin in ofono can probably do this. Ideally,
GSM should go offline when this component fails, so that SMSes are
queued by the network.
There should be "ph primary" component responsible for calls and
incoming SMSes -- mostly for actions not initiated by local user. On
incoming events, it should play a melody. For calls, it should set up
mixers, and display a window allowing user to manipulate volume,
answer, reject and terminate the call. For incoming message,
notification window should be displayed.
"ph monitor" should be usable for monitoring phone status from the
command line, displaying current network and signal status, any
incoming calls and messages.
There should be a GUI component for doing actions for local user. It
should allow basic control (online/airplane mode, starting data
connection), allow placing phone calls (but audio will be controlled
and call window will still be displayed by "ph primary"), and sending
SMS messages.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
11 months, 1 week
[OFONO][Gemalto] Sent SMS status
by wajdi zairi
Hi all ,
We are planning to add a feature to handle sent SMS status . The available
OFONO APIs to use seems provided by *org.ofono.Message* but when i made
some tests
to catch the *PropertyChanged* signal on a sent SMS i notes that the result
is always "sent" (when out from TX) even on a wrong destination number .
# signal sender=:1.12 -> dest=(null destination) serial=105
path=/gemalto_0/message_2F3426EAC5E3EBA365FA626347886C0EC4DC5323;
interface=org.ofond
string "State"
variant string "sent"
Also the call of *org.ofono.Message.GetProperties*() on given message
object path will fail since ofono is removing to object after sending
(sms_tx_queue_remove_entry) .
So here the "sent" means that the message was treated and out from TX but
does not give the real state if it was delivered or not .
I made a try by adding History driver to our Gemalto drivers and it gives a
better result regarding SMS delivery status which meet our requirements.
To keep our ofono aligned with latest ofono updates, we want to upstream
our contributions so i want to get your opinion about a propasal upstream
candidate :
- Add history driver implementation to drivers/gemaltomodems/
- Add signal in plugins/gemalto.c to notify the different sent messages
status (indicated on enum*ofono_history_sms_status* )
- Then the signal can be consumed by any client after sending an SMS .
Please correct me if something wrong and if you have any sugesstion.
Thank you in advance !
Kind Regards,
Wajdi ZAIRI
Embedded Software Engineer
11 months, 1 week
