Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asterisk 10, 11, 13, 14 compatibility fixes. And a few other fixes. #216

Open
wants to merge 137 commits into
base: master
Choose a base branch
from

Conversation

wdoekes
Copy link

@wdoekes wdoekes commented Sep 6, 2015

Here you go.

Author: me, some time in the past.
Source: /~dexter/work/asterisk-chan-dongle/patch.patch.txt
Author: me, some time in the past.
Source: /~dexter/work/asterisk-chan-dongle/patch2.patch.txt
Author: me, some time in the past.
Source: /~dexter/work/asterisk-chan-dongle/patch3.patch.txt
Author: me, in August 2013.
Author: novaktmp, 2014-12-01 17:42:52
Source: https://forum.openwrt.org/viewtopic.php?id=54343

Slight adaptations by me.
Author: mio
Source: bg111#153

Not using full 3GPP version from https://code.google.com/p/
  asterisk-chan-dongle/issues/detail?id=140 because of the issues
described there.

This should simply fix that you don't get a truncated SMS because of an
@ sign.
@bg111
Copy link
Owner

bg111 commented Sep 9, 2015

i check ast_channel_cleanup() same as ast_channel_unref but with NULL check.
So ast_channel_cleanup() is ok

@thelan
Copy link

thelan commented Oct 29, 2015

Hello,

Testes with asterisk 11.17.1. Works great!

@mj84
Copy link

mj84 commented Dec 8, 2015

Any chance this will be merged with upstream?

As suggested by @arekm. Note that "010813" does not work, as gcc will treat
it as base 8.
@itamarjp
Copy link

please merge, thank you.

According to the bug report by Marcelo Fernandes Vianna:
> Under some circumstances (if parsing the sms returns -1 in
> at_response.c), even if sms is disabled in dongle.conf,
> receiving a sms can still crash an ongoing call.

Thanks for the suggested patch. Refactored and merged.
Closes #7.
Declare AST_MODULE_SELF_SYM=__internal_$(module_name)_self.
Character conversion assumed UCS-2, which handles only the Basic
Multilingual Plane, but various parties will have switched to using
UTF-16 there.

Fix suggested by @fadasi. Reported and tested by @pjmichel. Thanks!
Closes #8.
@fadasi observed addresses with 0xD0 and 0xD1 (NPI is UNKNOWN or E164)
in the wild. Fix comparisons to only check the TON.

Closes #9.
Merge fixes from upstream bg111/asterisk-chan-dongle
wdoekes and others added 30 commits June 19, 2020 13:21
Add guard against NULL args.payload

Thanks Vladimir Serbinenko!
"Removed some magic. Sorry, I'm not a wizard"

Thanks @p-velasco!
Better type safety of SMS handling and error suppression on initial SMS poll.

Thanks @4e4o
The correct device interfaces for HUAWEI E171 modem is  3,2  . the 1,2 interface order does not work. 

Model: E171
Firmware: 21.156.00.00.143
IMEI: 861496015775578
Updated ports for E153Du-1
IMEI: 868672001033577
Totally untested. Might close #144.

Based on this patch:

    From d332203 Mon Sep 17 00:00:00 2001
    From: Sebastian Kemper <[email protected]>
    Date: Thu, 9 Sep 2021 11:14:30 +0200
    Subject: [PATCH] Dongle to Quectel changes

    Signed-off-by: Sebastian Kemper <[email protected]>
    ---
     at_command.c | 4 ++--
     pdiscovery.c | 1 +
     2 files changed, 3 insertions(+), 2 deletions(-)

    diff --git a/at_command.c b/at_command.c
    index 4882d82..684e821 100644
    --- a/at_command.c
    +++ b/at_command.c
    @@ -33,7 +33,7 @@ static const char cmd_at[] 	 = "AT\r";
     static const char cmd_chld1x[]   = "AT+CHLD=1%d\r";
     static const char cmd_chld2[]    = "AT+CHLD=2\r";
     static const char cmd_clcc[]     = "AT+CLCC\r";
    -static const char cmd_ddsetex2[] = "AT^DDSETEX=2\r";
    +static const char cmd_ddsetex2[] = "AT+QPCMV=1,0\r";

     /*!
      * \brief Format and fill generic command
    @@ -128,7 +128,7 @@ EXPORT_DEF int at_enqueue_initialization(struct cpvt *cpvt, at_cmd_t from_comman
     	static const char cmd15[] = "AT+CREG?\r";
     	static const char cmd16[] = "AT+CNUM\r";

    -	static const char cmd17[] = "AT^CVOICE?\r";
    +	static const char cmd17[] = "AT+QPCMV?\r";
     //	static const char cmd18[] = "AT+CLIP=0\r";
     	static const char cmd19[] = "AT+CSSN=1,1\r";
     	static const char cmd20[] = "AT+CMGF=0\r";
    diff --git a/pdiscovery.c b/pdiscovery.c
    index 006c5d8..c599c23 100644
    --- a/pdiscovery.c
    +++ b/pdiscovery.c
    @@ -68,6 +68,7 @@ static const struct pdiscovery_device device_ids[] = {
             { 0x12d1, 0x14ac, { 4, 3, /* 0 */ } },          /* E153Du-1 : thanks mghadam */
     	{ 0x12d1, 0x1436, { 4, 3, /* 0 */ } },		/* E1750 */
     	{ 0x12d1, 0x1506, { 3, 2, /* 0 */ } },		/* E171 firmware 21.x : thanks Sergey Ivanov */
    +	{ 0x2c7c, 0x0125, { 1, 4, /* 0 */ } },		/* Dongle EC25-A LTE modem */
     };

     static struct discovery_cache cache;
It's no longer used
Non-Quectel tested by Deomid Ryabkov. Also includes better -Werror
behaviour.

Quectel support untested thusfar. We'll see how that goes.
The uint16_t bytes are the other way around.
ATQ_CMD_DECLARE_STI adds ATQ_CMD_FLAG_IGNORE so the error response on
either command does not abort the entire initialization task.

Without it, we migh get:

    [AT+QPCMV?]
    remove command 'AT+QPCMV' expected response 'OK' real 'ERROR' cmd
      16/22 flags 0x01 from queue
    remove task with 22 command(s) begin with 'AT' expected response
      'OK' from queue

where the failed AT+QPCMV? aborts the 22-item init task.

Closes #148, reported and tested by @AlexHighTower.
> i think these lines can also be removed, since ATQ_CMD_DECLARE_STI
> will plow ahead anyway, no need to manually restart the sequence.

Dixit, @rojer in #148. I don't know. Sounds plausible.
This reverts commit f1517b4.

See discussion on:
f1517b4

There @Vald3m argues that the old values were correct.
Some libc implementations are shifting toward using 64-bit time_t for
all arches to solve the year 2038 problem. musl is one of them, see [1].

So when compiling for a 32-bit arch time_t will be long long. This
commit adds this option.

[1] https://musl.libc.org/time64.html

Signed-off-by: Sebastian Kemper <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.