August 2020 - ofono - Ml01.01.Org

Application of using the best VPN for Mac

by sofiamartin082＠gmail.com

FastestVPN was founded in the year 2017 with all the latest features and trinkets, when it comes to your Mac device you certainly deserve the best VPN for Mac, which is also why FastestVPN aims to deliver you top quality service regardless of where you are. https://fastestvpn.com/download/mac-vpn

3 months, 1 week

2
1
0 / 1

[PATCH 1/1] remove obsolete m4 macro

by Nikhil Jha

As per https://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html LT_INIT should be used instead. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 3655a112..06ba5290 100644 --- a/configure.ac +++ b/configure.ac @@ -28,7 +28,7 @@ m4_define([_LT_AC_TAGCONFIG], []) m4_ifdef([AC_LIBTOOL_TAGS], [AC_LIBTOOL_TAGS([])]) AC_DISABLE_STATIC -AC_PROG_LIBTOOL +LT_INIT AC_ARG_ENABLE(optimization, AC_HELP_STRING([--disable-optimization], [disable code optimization through compiler]), [ -- 2.26.2

7 months, 2 weeks

2
1
0 / 0

Unable to establish ppp connection with Huawei dongle

by rakespani＠gmail.com

Hi , I am trying to enable lte connection with huawei dongle , but I am getting below error log for activat/context. Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: Modem: > AT+CGDCONT=1,"IP","airtelgprs.com"\r Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: Modem: < \r\nOK\r\n Aug 26 11:36:28 raspberrypi3 daemon.debug ofonod[147]: ../ofono-1.24/drivers/atmodem/gprs-context.c:at_cgdcont_cb() ok 1 Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: Modem: > AT+CGDATA="PPP",1\r Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: Modem: < \r\nCONNECT 100000000\r\n Aug 26 11:36:28 raspberrypi3 daemon.debug ofonod[147]: ../ofono-1.24/drivers/atmodem/gprs-context.c:at_cgdata_cb() ok 1 Aug 26 11:36:28 raspberrypi3 daemon.debug ofonod[147]: ../ofono-1.24/drivers/atmodem/gprs-context.c:setup_ppp() Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 0:INITIAL Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: event: 0 (Up), action: 2, new_state: 2 (CLOSED) Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 2:CLOSED Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: event: 2 (Open), action: 1026, new_state: 6 (REQSENT) Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_initialize_restart_count: current state 2:CLOSED Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 2:CLOSED Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: ../ofono-1.24/gatchat/gatppp.c:ppp_enter_phase() 1 Aug 26 11:36:29 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^BOOT:1113056,0,0,0,99\r\n Aug 26 11:36:30 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n Aug 26 11:36:30 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n Aug 26 11:36:31 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT Aug 26 11:36:31 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT Aug 26 11:36:31 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT) Aug 26 11:36:31 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT Aug 26 11:36:33 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n Aug 26 11:36:33 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n Aug 26 11:36:34 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT Aug 26 11:36:34 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT Aug 26 11:36:34 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT) Aug 26 11:36:34 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT Aug 26 11:36:36 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n Aug 26 11:36:36 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n Aug 26 11:36:37 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT Aug 26 11:36:37 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT Aug 26 11:36:37 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT) Aug 26 11:36:37 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT Aug 26 11:36:39 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n\r\n^LTERSRP:-76,-6\r\n Aug 26 11:36:40 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT Aug 26 11:36:40 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT Aug 26 11:36:40 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT) Aug 26 11:36:40 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT Aug 26 11:36:42 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n Aug 26 11:36:42 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n Aug 26 11:36:43 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT Aug 26 11:36:43 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT Aug 26 11:36:43 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT) Aug 26 11:36:43 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT Aug 26 11:36:45 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n Aug 26 11:36:45 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n Aug 26 11:36:46 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT Aug 26 11:36:46 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT Aug 26 11:36:46 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT) Aug 26 11:36:46 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT Aug 26 11:36:48 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n Aug 26 11:36:48 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n Aug 26 11:36:49 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT Aug 26 11:36:49 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT Aug 26 11:36:49 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT) Aug 26 11:36:49 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT Aug 26 11:36:51 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n Aug 26 11:36:51 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n Aug 26 11:36:52 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT Aug 26 11:36:52 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT Aug 26 11:36:52 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT) Aug 26 11:36:52 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT Aug 26 11:36:54 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n Aug 26 11:36:54 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-9\r\n Aug 26 11:36:55 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT Aug 26 11:36:55 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT Aug 26 11:36:55 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT) Aug 26 11:36:55 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT Aug 26 11:36:57 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n Aug 26 11:36:57 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-7\r\n Aug 26 11:36:58 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT Aug 26 11:36:58 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT Aug 26 11:36:58 raspberrypi3 daemon.info ofonod[147]: PPP: event: 5 (TO-), action: 803, new_state: 3 (STOPPED) Aug 26 11:36:58 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_this_layer_finished: current state 3:STOPPED Aug 26 11:36:58 raspberrypi3 daemon.info ofonod[147]: PPP: ../ofono-1.24/gatchat/gatppp.c:ppp_enter_phase() 0 Aug 26 11:36:58 raspberrypi3 daemon.info ofonod[147]: PPP: ../ofono-1.24/gatchat/gatppp.c:ppp_dead() Aug 26 11:36:58 raspberrypi3 daemon.debug ofonod[147]: ../ofono-1.24/drivers/atmodem/gprs-context.c:ppp_disconnect() Reason: 0 Aug 26 11:36:58 raspberrypi3 daemon.debug ofonod[147]: ../ofono-1.24/src/gprs.c:pri_activate_callback() 0x165b9a8 Aug 26 11:36:58 raspberrypi3 daemon.debug ofonod[147]: ../ofono-1.24/src/gprs.c:pri_activate_callback() Activating context failed with error: Unknown error type

8 months, 2 weeks

3
4
0 / 0

[PATCH v2] atmodem: Detect usage of AT+CGEREP

by poeschel＠lemonage.de

From: Lars Poeschel <poeschel(a)lemonage.de> Currently AT+CGEREP=2,1 is sent in case we don't know what the modem needs. (default case) Not all modems understand this. So, we first query what the modem supports with AT+CGEREP=? and then use this information to be nice to the modem. This way modems, like the Quectel M95 that do only understand AT+CGEREP=1 do also work nicely. --- drivers/atmodem/gprs.c | 59 ++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 57 insertions(+), 2 deletions(-) diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs.c index 68470f11..443bdf77 100644 --- a/drivers/atmodem/gprs.c +++ b/drivers/atmodem/gprs.c @@ -45,6 +45,7 @@ #define MAX_CONTEXTS 255 static const char *cgreg_prefix[] = { "+CGREG:", NULL }; +static const char *cgerep_prefix[] = { "+CGEREP:", NULL }; static const char *cgdcont_prefix[] = { "+CGDCONT:", NULL }; static const char *cgact_prefix[] = { "+CGACT:", NULL }; static const char *none_prefix[] = { NULL }; @@ -648,6 +649,60 @@ static void gprs_initialized(gboolean ok, GAtResult *result, gpointer user_data) ofono_gprs_register(gprs); } +static void at_cgerep_test_cb(gboolean ok, GAtResult *result, + gpointer user_data) +{ + struct ofono_gprs *gprs = user_data; + struct gprs_data *gd = ofono_gprs_get_data(gprs); + GAtResultIter iter; + int min, max, arg1 = 0, arg2 = 0; + gboolean two_arguments = true; + char buf[20]; + + if (!ok) + return; + + g_at_result_iter_init(&iter, result); + + g_at_result_iter_next(&iter, "+CGEREP:"); + + if (!g_at_result_iter_open_list(&iter)) + return; + + while (g_at_result_iter_next_range(&iter, &min, &max)) { + if ((min <= 1) && (max >= 1)) + arg1 = 1; + + if ((min <= 2) && (max >= 2)) + arg1 = 2; + } + + if (!g_at_result_iter_close_list(&iter)) + return; + + if (!g_at_result_iter_open_list(&iter)) { + two_arguments = false; + goto out; + } + + while (g_at_result_iter_next_range(&iter, &min, &max)) { + if (min <= 1 <= max) + arg2 = 1; + } + + if (!g_at_result_iter_close_list(&iter)) + return; + +out: + if (two_arguments) + sprintf(buf, "AT+CGEREP=%u,%u", arg1, arg2); + else + sprintf(buf, "AT+CGEREP=%u", arg1); + + g_at_chat_send(gd->chat, buf, none_prefix, gprs_initialized, gprs, + NULL); +} + static void at_cgreg_test_cb(gboolean ok, GAtResult *result, gpointer user_data) { @@ -702,8 +757,8 @@ retry: gprs_initialized, gprs, NULL); break; default: - g_at_chat_send(gd->chat, "AT+CGEREP=2,1", none_prefix, - gprs_initialized, gprs, NULL); + g_at_chat_send(gd->chat, "AT+CGEREP=?", cgerep_prefix, + at_cgerep_test_cb, gprs, NULL); break; } -- 2.28.0

8 months, 2 weeks

2
1
0 / 0

[PATCH 1/2] atmodem: Detect usage of AT+CGEREP

by poeschel＠lemonage.de

From: Lars Poeschel <poeschel(a)lemonage.de> Currently AT+CGEREP=2,1 is sent in case we don't know what the modem needs. (default case) Not all modems understand this. So, we first query what the modem supports with AT+CGEREP=? and then use this information to be nice to the modem. This way modems, like the Quectel M95 that do only understand AT+CGEREP=1 do also work nicely. --- drivers/atmodem/gprs.c | 75 ++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 73 insertions(+), 2 deletions(-) diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs.c index d829e2e6..3900b95b 100644 --- a/drivers/atmodem/gprs.c +++ b/drivers/atmodem/gprs.c @@ -45,6 +45,7 @@ #define MAX_CONTEXTS 255 static const char *cgreg_prefix[] = { "+CGREG:", NULL }; +static const char *cgerep_prefix[] = { "+CGEREP:", NULL }; static const char *cgdcont_prefix[] = { "+CGDCONT:", NULL }; static const char *cgact_prefix[] = { "+CGACT:", NULL }; static const char *none_prefix[] = { NULL }; @@ -647,6 +648,76 @@ static void gprs_initialized(gboolean ok, GAtResult *result, gpointer user_data) ofono_gprs_register(gprs); } +static void at_cgerep_test_cb(gboolean ok, GAtResult *result, + gpointer user_data) +{ + struct ofono_gprs *gprs = user_data; + struct gprs_data *gd = ofono_gprs_get_data(gprs); + GAtResultIter iter; + int min1, max1 = 1, min2, max2 = 1; + gboolean two_arguments = true; + char buf[20]; + + if (!ok) + return; + + g_at_result_iter_init(&iter, result); + + g_at_result_iter_next(&iter, "+CGEREP:"); + + if (!g_at_result_iter_open_list(&iter)) + return; + + if (!g_at_result_iter_next_range(&iter, &min1, &max1)) + return; + + /* if min1 == max1 we had no range but a list and that + * means we are interested in the last number of that list*/ + if (min1 == max1) { + while (!g_at_result_iter_close_list(&iter)) { + if (!g_at_result_iter_next_number(&iter, &max1)) + break; + } + } + + if (!g_at_result_iter_skip_next(&iter)) { + two_arguments = false; + goto out; + } + + if (!g_at_result_iter_open_list(&iter)) { + two_arguments = false; + goto out; + } + + if (!g_at_result_iter_next_range(&iter, &min2, &max2)) { + two_arguments = false; + goto out; + } + + if (min2 == max2) { + while (!g_at_result_iter_close_list(&iter)) { + if (!g_at_result_iter_next_number(&iter, &max2)) { + break; + } + } + } + +out: + if (max1 > 2) + max1 = 2; + + if (max2 > 1) + max2 = 1; + + if (two_arguments) + sprintf(buf, "AT+CGEREP=%u,%u", max1, max2); + else + sprintf(buf, "AT+CGEREP=%u", max1); + + g_at_chat_send(gd->chat, buf, none_prefix, gprs_initialized, gprs, NULL); +} + static void at_cgreg_test_cb(gboolean ok, GAtResult *result, gpointer user_data) { @@ -701,8 +772,8 @@ retry: gprs_initialized, gprs, NULL); break; default: - g_at_chat_send(gd->chat, "AT+CGEREP=2,1", none_prefix, - gprs_initialized, gprs, NULL); + g_at_chat_send(gd->chat, "AT+CGEREP=?", cgerep_prefix, + at_cgerep_test_cb, gprs, NULL); break; } -- 2.27.0

8 months, 2 weeks

3
8
0 / 0

[PATCH v2] atmodem: Signal quality on quectel serial modems

by poeschel＠lemonage.de

From: Lars Poeschel <poeschel(a)lemonage.de> As the default way of getting the signal quality with +CIND is also unstable on quectel serial modems (the same as on quectel EC21). In fact the signal quality is only updated on cell changes. Those trigger a manual AT+CSQ in ofono and get an update this way, but the URCs do not work. So we implement a quectelish way here as well. The quectelish way is very similar to the way ifx modems work. We can reuse their csq_notify function. --- drivers/atmodem/network-registration.c | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/drivers/atmodem/network-registration.c b/drivers/atmodem/network-registration.c index 78b1994c..c1309f61 100644 --- a/drivers/atmodem/network-registration.c +++ b/drivers/atmodem/network-registration.c @@ -780,15 +780,26 @@ static void ifx_xciev_notify(GAtResult *result, gpointer user_data) */ } -static void ifx_xcsq_notify(GAtResult *result, gpointer user_data) +static void ifx_quec_csq_notify(GAtResult *result, gpointer user_data) { struct ofono_netreg *netreg = user_data; + struct at_netreg_data *nd = ofono_netreg_get_data(netreg); int rssi, ber, strength; GAtResultIter iter; + const char *prefix; g_at_result_iter_init(&iter, result); - if (!g_at_result_iter_next(&iter, "+XCSQ:")) + switch (nd->vendor) { + case OFONO_VENDOR_QUECTEL_SERIAL: + prefix = "+CSQN:"; + break; + default: + prefix = "+XCSQ:"; + break; + } + + if (!g_at_result_iter_next(&iter, prefix)) return; if (!g_at_result_iter_next_number(&iter, &rssi)) @@ -2027,7 +2038,7 @@ static void at_creg_set_cb(gboolean ok, GAtResult *result, gpointer user_data) /* Register for specific signal strength reports */ g_at_chat_register(nd->chat, "+XCIEV:", ifx_xciev_notify, FALSE, netreg, NULL); - g_at_chat_register(nd->chat, "+XCSQ:", ifx_xcsq_notify, + g_at_chat_register(nd->chat, "+XCSQ:", ifx_quec_csq_notify, FALSE, netreg, NULL); g_at_chat_send(nd->chat, "AT+XCSQ=1", none_prefix, NULL, NULL, NULL); @@ -2118,6 +2129,13 @@ static void at_creg_set_cb(gboolean ok, GAtResult *result, gpointer user_data) g_at_chat_send(nd->chat, "AT+QINDCFG=\"act\",1", none_prefix, NULL, NULL, NULL); break; + case OFONO_VENDOR_QUECTEL_SERIAL: + g_at_chat_register(nd->chat, "+CSQN:", + ifx_quec_csq_notify, FALSE, netreg, NULL); + /* Register for specific signal strength reports */ + g_at_chat_send(nd->chat, "AT+QEXTUNSOL=\"SQ\",1", none_prefix, + NULL, NULL, NULL); + break; default: g_at_chat_send(nd->chat, "AT+CIND=?", cind_prefix, cind_support_cb, netreg, NULL); -- 2.27.0

8 months, 3 weeks

2
1
0 / 0

[RFC PATCH] atmodem: Signal quality on quectel serial modems

by poeschel＠lemonage.de

From: Lars Poeschel <poeschel(a)lemonage.de> As the default way of getting the signal quality with +CIND is also unstable on quectel serial modems (the same as on quectel EC21). In fact the signal quality is only updated on cell changes. Those trigger a manual AT+CSQ in ofono and get an update this way, but the URCs do not work. So we implement a quectelish way here as well. --- >8 --- I send this patch as a RFC because the quectel_csqn_notify function very much duplicates the ifx_xcsq_notify function despite the "+CSQN" string. I did not see a good way to reuse the already existing function because the callback interface only has one user defined pointer and this is used by the struct ofono_netreg pointer already. Does anyone have a better idea ? Thanks, Lars --- drivers/atmodem/network-registration.c | 34 ++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/drivers/atmodem/network-registration.c b/drivers/atmodem/network-registration.c index 78b1994c..74829201 100644 --- a/drivers/atmodem/network-registration.c +++ b/drivers/atmodem/network-registration.c @@ -1017,6 +1017,33 @@ static void quectel_qind_notify(GAtResult *result, gpointer user_data) } } +static void quectel_csqn_notify(GAtResult *result, gpointer user_data) +{ + struct ofono_netreg *netreg = user_data; + int rssi, ber, strength; + GAtResultIter iter; + + g_at_result_iter_init(&iter, result); + + if (!g_at_result_iter_next(&iter, "+CSQN:")) + return; + + if (!g_at_result_iter_next_number(&iter, &rssi)) + return; + + if (!g_at_result_iter_next_number(&iter, &ber)) + return; + + DBG("rssi %d ber %d", rssi, ber); + + if (rssi == 99) + strength = -1; + else + strength = (rssi * 100) / 31; + + ofono_netreg_strength_notify(netreg, strength); +} + static gboolean notify_time(gpointer user_data) { struct ofono_netreg *netreg = user_data; @@ -2118,6 +2145,13 @@ static void at_creg_set_cb(gboolean ok, GAtResult *result, gpointer user_data) g_at_chat_send(nd->chat, "AT+QINDCFG=\"act\",1", none_prefix, NULL, NULL, NULL); break; + case OFONO_VENDOR_QUECTEL_SERIAL: + g_at_chat_register(nd->chat, "+CSQN:", + quectel_csqn_notify, FALSE, netreg, NULL); + /* Register for specific signal strength reports */ + g_at_chat_send(nd->chat, "AT+QEXTUNSOL=\"SQ\",1", none_prefix, + NULL, NULL, NULL); + break; default: g_at_chat_send(nd->chat, "AT+CIND=?", cind_prefix, cind_support_cb, netreg, NULL); -- 2.27.0

9 months

3
2
0 / 0

[PATCH v2 0/3] gemalto: USB ethernet data path for ELS81x

by Sergey Matyukevich

Hi Denis and all, This patch series enables USB ethernet data path for gemalto modems that support this feature, in particular for ELS81x devices. Regards, Sergey v1 -> v2 - replace g_try_new0 by use g_new0 - drop patch with incorrect fix for modem init Sergey Matyukevich (3): drivers: gemalto: add gprs-context driver plugins: udevng: detect gemalto network interfaces plugins: gemalto: alternative gprs-context driver Makefile.am | 3 +- drivers/gemaltomodem/gemaltomodem.c | 4 +- drivers/gemaltomodem/gemaltomodem.h | 3 + drivers/gemaltomodem/gprs-context.c | 278 ++++++++++++++++++++++++++++ plugins/gemalto.c | 12 +- plugins/udevng.c | 14 +- 6 files changed, 308 insertions(+), 6 deletions(-) create mode 100644 drivers/gemaltomodem/gprs-context.c -- 2.28.0

9 months

2
4
0 / 0

[RFC PATCH 0/4] gemalto: USB ethernet data path for ELS81x

by Sergey Matyukevich

Hi Denis and all, This patch series suggests several updates and fixes for gemalto modems, in particular for ELS81x device. Major change enables data path via USB ethernet interface for modems supporting this feature. Before submitting this patch series, I figured out that similar changes have been already submitted to ofono mailing list back in 2017. At that time they were aimed at PLS8 device: https://lists.syncevolution.org/hyperkitty/list/ofono@ofono.org/thread/CH... It looks like not all the pieces from the original patches finally landed in the ofono code base. I am not sure why they were not merged, so I marked this series as RFC. Regards, Sergey Sergey Matyukevich (4): drivers: gemalto: add gprs-context driver plugins: udevng: detect gemalto network interfaces plugins: gemalto: add optional gprs-context driver plugins: gemalto: fix incomplete at-chat shutdown Makefile.am | 3 +- drivers/gemaltomodem/gemaltomodem.c | 4 +- drivers/gemaltomodem/gemaltomodem.h | 3 + drivers/gemaltomodem/gprs-context.c | 280 ++++++++++++++++++++++++++++ plugins/gemalto.c | 20 +- plugins/udevng.c | 14 +- 6 files changed, 318 insertions(+), 6 deletions(-) create mode 100644 drivers/gemaltomodem/gprs-context.c -- 2.28.0

9 months

3
10
0 / 0

[PATCH v4] gprs: Quectel EC21 does not understand AT+CPSB

by poeschel＠lemonage.de

From: Lars Poeschel <poeschel(a)lemonage.de> The Quectel EC21 modem does not understand the AT+CPSB command, and we did not find a suitable replacement in the Quectel_EC25&EC21_AT_Commands_Manual_V1.3.pdf AT+CPSB gives an error on this modem, so we just skip it. --- drivers/atmodem/gprs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs.c index b637f733..d829e2e6 100644 --- a/drivers/atmodem/gprs.c +++ b/drivers/atmodem/gprs.c @@ -624,6 +624,8 @@ static void gprs_initialized(gboolean ok, GAtResult *result, gpointer user_data) g_at_chat_send(gd->chat, "AT#PSNT=1", none_prefix, NULL, NULL, NULL); break; + case OFONO_VENDOR_QUECTEL_EC2X: + break; default: g_at_chat_register(gd->chat, "+CPSB:", cpsb_notify, FALSE, gprs, NULL); -- 2.27.0

9 months

2
1
0 / 0

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ofono August 2020