Closed johandeclercqdemocon closed 4 years ago
razvancrainea
commented
4 years ago The problem is that GSM7 is not fully compatible with the UTF-8 encoding, and there's no re-encoding done by OpenSIPS. I will shortly push a fix for this. Please test and let us know if there are any issues with this.
johandeclercqdemocon
commented
4 years ago OK, so at least you had enough logs :-)
On Mon, 13 Jan 2020, 13:23 Răzvan Crainea, notifications@github.com wrote:
The problem is that GSM7 is not fully compatible with the UTF-8 encoding, and there's no re-encoding done by OpenSIPS. I will shortly push a fix for this. Please test and let us know if there are any issues with this.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/OpenSIPS/opensips/issues/1935?email_source=notifications&email_token=AKDSPWNS4BPDMWZFDT2Z6V3Q5RMNTA5CNFSM4KFFUZX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIYQPCA#issuecomment-573638536, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKDSPWO6XI6L2ENC7L2M7MLQ5RMNTANCNFSM4KFFUZXQ .
volga629-1
commented
4 years ago Hello @razvancrainea I am trying back port to 3.0.1 and latest fixes produce error on attempt to compile Any help thank you
I copied latest smpp.c and did diff with smpp.c in 3.0.1 tar to create diff with latest fixes.
smpp.c: In function 'increment_chunk_identifier':
smpp.c:654:18: error: 'smpp_session_t' {aka 'struct smpp_session'} has no member named 'chunk_identifier'
seq_no = session->chunk_identifier++;
^~
smpp.c: In function 'send_submit_or_deliver_request':
smpp.c:1255:54: error: 'MAX_SMS_CHARACTERS' undeclared (first use in this function); did you mean 'MAX_MI_PARAMS'?
if ( (msg_type == SMPP_CODING_DEFAULT && msg->len > MAX_SMS_CHARACTERS) ||
^~~~~~~~~~~~~~~~~~
MAX_MI_PARAMS
smpp.c:1255:54: note: each undeclared identifier is reported only once for each function it appears in
smpp.c: In function 'recv_smpp_msg':
smpp.c:1346:25: error: 'MAX_SMS_CHARACTERS' undeclared (first use in this function); did you mean 'MAX_MI_PARAMS'?
static char sms_body[2*MAX_SMS_CHARACTERS];
^~~~~~~~~~~~~~~~~~
MAX_MI_PARAMS
smpp.c:1346:14: warning: unused variable 'sms_body' [-Wunused-variable]
static char sms_body[2*MAX_SMS_CHARACTERS];
^~~~~~~~
make[1]: *** [../../Makefile.rules:25: smpp.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/volga629/rpmbuild/BUILD/opensips-3.0.1/modules/proto_smpp'
make: *** [Makefile:200: modules] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.u94sR2 (%build)
RPM build errors:
I haven't got a chance to backport to 3.0 yet, will try do do this when possible.
razvancrainea
commented
4 years ago I've just backported the commit in 3.0. Please give it a try and close the ticket if the issue is no longer happening.
volga629-1
commented
4 years ago Back port patch is failing
cat ~/rpmbuild/SOURCES/opensips-3.0.0-proto_smpp-latest-fix-GSM7-mem-leak.patch | /usr/bin/patch --no-backup-if-mismatch -p1 --fuzz=0
patching file modules/proto_smpp/smpp.c
Hunk #1 FAILED at 350.
Hunk #2 FAILED at 395.
Hunk #3 FAILED at 1092.
Hunk #4 FAILED at 1122.
Hunk #5 FAILED at 1143.
5 out of 5 hunks FAILED -- saving rejects to file modules/proto_smpp/smpp.c.rejBuild failing at
smpp.c:1169:5: error: conflicting types for 'send_submit_or_deliver_request'
int send_submit_or_deliver_request(str *msg, str *src, str *dst,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from smpp.c:43:
proto_smpp.h:72:5: note: previous declaration of 'send_submit_or_deliver_request' was here
int send_submit_or_deliver_request(str *msg, int msg_type, str *src, str *dst,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [../../Makefile.rules:25: smpp.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/volga629/rpmbuild/BUILD/opensips-3.0.1/modules/proto_smpp'
make: *** [Makefile:200: modules] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.Le0gQ7 (%build)
RPM build errors:
Volga, is it the same thing as I reported yesterday ?
Outlook voor iOShttps://aka.ms/o0ukef downloaden
Van: volga629-1 notifications@github.com Verzonden: dinsdag, januari 14, 2020 5:52 PM Aan: OpenSIPS/opensips CC: johandeclercqdemocon; Author Onderwerp: Re: [OpenSIPS/opensips] [BUG] tcp reads buffer correctly for smpp but when reading the body, it drops the part after 0x00 character. (#1935)
Build failing at
smpp.c:1169:5: error: conflicting types for 'send_submit_or_deliver_request'
int send_submit_or_deliver_request(str msg, str src, str dst,
^~~~~~~~~~
In file included from smpp.c:43:
proto_smpp.h:72:5: note: previous declaration of 'send_submit_or_deliver_request' was here
int send_submit_or_deliver_request(str msg, int msg_type, str src, str dst,
^~~~~~~~~~
make[1]: [../../Makefile.rules:25: smpp.o] Error 1
make[1]: Waiting for unfinished jobs....
make[1]: Leaving directory '/home/volga629/rpmbuild/BUILD/opensips-3.0.1/modules/proto_smpp'
make: *** [Makefile:200: modules] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.Le0gQ7 (%build)
RPM build errors:
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/OpenSIPS/opensips/issues/1935?email_source=notifications&email_token=AKDSPWMAH4IBOBPUTDTTOBTQ5XUVBA5CNFSM4KFFUZX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI5KSWY#issuecomment-574269787, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKDSPWLAC5MAQ2MWC276FITQ5XUVBANCNFSM4KFFUZXQ.
volga629-1
commented
4 years ago No that look like some function conflict, @razvancrainea can give us insight on issue
razvancrainea
commented
4 years ago Not sure what you're talking to, the commit applies just fine on 3.0: https://travis-ci.org/OpenSIPS/opensips/jobs/636902294 I suspect you have your own code there, so I can't help you that much, as I'm not maintaining that, so I don't know what you've done there.
volga629-1
commented
4 years ago We don't have extra code That patch seem the same It just some confusion, what should be include it. Can you please provide patch link with you fixes for 3.0.0 branch. If I do just diff of the commit for 3.0.0 branch patch is failing on 3.0.1 tar ball.
[volga629@canldev01-fedora29 SPECS]$ cat ~/rpmbuild/SOURCES/opensips-3.0.0-proto_smpp-latest-fix-GSM7-mem-leak.patch
--- a/modules/proto_smpp/smpp.c 2020-01-14 09:26:40.809769074 -0500
+++ b/modules/proto_smpp/smpp.c 2020-01-14 11:39:01.915437530 -0500
@@ -55,6 +55,15 @@
static uint32_t increment_sequence_number(smpp_session_t *session);
+#define free_smpp_msg(_msg) \
+ do { \
+ pkg_free((_msg)->header); \
+ pkg_free((_msg)->body); \
+ if ((_msg)->payload.s) \
+ pkg_free((_msg)->payload.s); \
+ pkg_free((_msg)); \
+ } while (0)
+
/** TM bind */
struct tm_binds tmb;
@@ -341,12 +350,100 @@
err:
return -1;
}
-
-static int build_submit_or_deliver_request(smpp_submit_sm_req_t **preq, str *src, str *dst, str *message, int message_type, smpp_session_t *session,int *delivery_confirmation)
+static int convert_gsm7_to_utf8(unsigned char *input, int input_len, char *output)
{
- int i,hex_4grp,hex_val;
- char *p;
+ static unsigned int table_gsm7_to_utf8[] = {\
+ '@', 0xA3, '$', 0xA5, 0xE8, 0xE9, 0xF9, 0xEC,
+ 0xF2, 0xC7, 0x10, 0xd8, 0xF8, 0x13, 0xC5, 0xE5,
+ 0x394, '_', 0x3A6, 0x393, 0x39B, 0x3A9, 0x3A0, 0x3A8,
+ 0x3A3, 0x398, 0x39E, '?', 0xC6, 0xE6, 0xDF, 0xC9,
+ ' ', '!', '"', '#', 0xA4, '%', '&', '\'',
+ '(', ')', '*', '+', ',', '-', '.', '/',
+ '0', '1', '2', '3', '4', '5', '6', '7',
+ '8', '9', ':', ';', '<', '=', '>', '?',
+ 0xA1, 'A', 'B', 'C', 'D', 'E', 'F', 'G',
+ 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O',
+ 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W',
+ 'X', 'Y', 'Z', 0xC4, 0xD6, 0xD1, 0xDC, 0xA7,
+ 0xBF, 'a', 'b', 'c', 'd', 'e', 'f', 'g',
+ 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o',
+ 'p', 'q', 'r', 's', 't', 'u', 'v', 'w',
+ 'x', 'y', 'z', 0xE4, 0xF6, 0xF1, 0xFC, 0xE0,
+ };
+ char *p = output;
+ int i, t;
+ unsigned char c;
+ for (i = 0; i < input_len; i++) {
+ c = input[i];
+ if (c == 0x1B) {
+ /* escaped character - check the next char */
+ switch (input[++i]) {
+ case 0x0A:
+ t = 0x0A; /* FF is a Page Break control, treated like LF */
+ break;
+ case 0x14:
+ t = '^';
+ break;
+ case 0x28:
+ t = '{';
+ break;
+ case 0x29:
+ t = '}';
+ break;
+ case 0x2F:
+ t = '\\';
+ break;
+ case 0x3C:
+ t = '[';
+ break;
+ case 0x3D:
+ t = '~';
+ break;
+ case 0x3E:
+ t = ']';
+ break;
+ case 0x40:
+ t = '|';
+ break;
+ case 0x65:
+ t = 0x20AC;
+ break;
+ default:
+ --i; /* consider the previous character */
+ case 0x0D: /* CR2 - control character */
+ case 0x1B: /* SS2 - Single shift Escape */
+ t = '?'; /* unknown extended char */
+ break;
+ }
+ } else if (c < 0x80)
+ t = table_gsm7_to_utf8[c];
+ else
+ t = c;
+ if (t > 0xFF) {
+ if (t > 0x10000) {
+ /* four bytes */
+ *p++ = 0xF0 | ((t >> 18) & 0x07); /* 11110xxx */
+ *p++ = 0x80 | ((t >> 12) & 0x3F); /* 10xxxxxx */
+ *p++ = 0x80 | ((t >> 6) & 0x3F); /* 10xxxxxx */
+ *p++ = 0x80 | (t & 0x3F); /* 10xxxxxx */
+ } else if (t > 0x800) {
+ /* three bytes */
+ *p++ = 0xE0 | ((t >> 12) & 0x0F); /* 1110xxxx */
+ *p++ = 0x80 | ((t >> 6) & 0x3F); /* 10xxxxxx */
+ *p++ = 0x80 | (t & 0x3F); /* 10xxxxxx */
+ } else {
+ /* two bytes */
+ *p++ = 0xC0 | ((t >> 6) & 0x1F); /* 110xxxxx */
+ *p++ = 0x80 | (t & 0x3F); /* 10xxxxxx */
+ }
+ } else
+ *p++ = (unsigned char )t; /* 0xxxxxxx */
+ }
+ return p - output;
+}
+static int build_submit_or_deliver_request(smpp_submit_sm_req_t **preq, str *src, str *dst, str *message, smpp_session_t *session)
+{
if (!preq || !src || !dst || !message) {
LM_ERR("NULL params");
goto err;
@@ -388,29 +485,8 @@
body->dest_addr_ton = session->dest_addr_ton;
body->dest_addr_npi = session->dest_addr_npi;
strncpy(body->destination_addr, dst->s, dst->len);
- if (message_type == 0) {
- body->sm_length = message->len;
- strncpy(body->short_message, message->s, message->len);
- } else {
- /* UTF-16 */
- body->data_coding = SMPP_CODING_UCS2;
- body->sm_length = message->len / 2;
-
- hex_val = 0;
- p = body->short_message;
- for (i=0;i<message->len;i++) {
- hex_4grp = hex2int(message->s[i]);
- if (i % 2 == 0) {
- hex_val = hex_4grp << 4;
- } else {
- hex_val |= hex_4grp;
- *p++ = hex_val;
- }
- }
- }
-
- if (delivery_confirmation && *delivery_confirmation > 0)
- body->registered_delivery = 1;
+ body->sm_length = message->len;
+ memcpy(body->short_message, message->s, message->len);
uint32_t body_len = get_payload_from_submit_sm_body(req->payload.s + HEADER_SZ, body);
@@ -603,7 +679,7 @@
n = tsend_stream(fd, req->payload.s, req->payload.len, smpp_send_timeout);
LM_DBG("sent %d bytes on smpp connection %p\n", n, conn);
free_req:
- pkg_free(req);
+ free_smpp_msg(req);
return n;
}
@@ -773,7 +849,7 @@
}
smpp_send_msg(session, &resp->payload);
- pkg_free(resp);
+ free_smpp_msg(resp);
}
uint32_t check_bind_session(smpp_bind_transceiver_t *body, smpp_session_t *session)
@@ -813,7 +889,7 @@
}
smpp_send_msg(session, &req->payload);
- pkg_free(req);
+ free_smpp_msg(req);
}
void handle_generic_nack_cmd(smpp_header_t *header, char *buffer, smpp_session_t *session)
@@ -1090,8 +1166,8 @@
}
-int send_submit_or_deliver_request(str *msg, int msg_type, str *src, str *dst,
- smpp_session_t *session, int *delivery_confirmation)
+int send_submit_or_deliver_request(str *msg, str *src, str *dst,
+ smpp_session_t *session)
{
smpp_submit_sm_req_t *req;
int ret;
@@ -1099,21 +1175,16 @@
LM_DBG("sending submit_sm\n");
LM_DBG("FROM: %.*s\n", src->len, src->s);
LM_DBG("TO: %.*s\n", dst->len, dst->s);
- LM_DBG("MESSAGE: %.*s type = %d\n", msg->len, msg->s,msg_type);
+ LM_DBG("MESSAGE: %.*s\n", msg->len, msg->s);
- if (build_submit_or_deliver_request(&req, src, dst, msg, msg_type,
- session,delivery_confirmation)) {
+ if (build_submit_or_deliver_request(&req, src, dst, msg, session)) {
LM_ERR("error creating submit_sm request\n");
return -1;
}
ret = smpp_send_msg(session, &req->payload);
- pkg_free(req);
-
- if (ret <=0)
- return -1;
-
- return 1;
+ free_smpp_msg(req);
+ return ret;
}
static void send_enquire_link_request(smpp_session_t *session)
@@ -1129,6 +1200,8 @@
session = list_entry(g_sessions->next, smpp_session_t, list);
smpp_send_msg(session, &req->payload);
+ pkg_free(req->header);
+ pkg_free(req->payload.s);
pkg_free(req);
}
@@ -1136,19 +1209,15 @@
smpp_session_t *session, struct receive_info *rcv)
{
static str msg_type = str_init("MESSAGE");
- static char sms_body[280];
+ char sms_body[4 * MAX_SMS_CHARACTERS]; /* 4 bytes for each char in UTF-8 */
char hdrs[1024];
char *p = hdrs;
char src[128];
sprintf(src, "sip:%s@%s:%d", body->source_addr, ip_addr2a(&rcv->src_ip), rcv->src_port);
char dst[128];
sprintf(dst, "sip:%s@%s:%d", body->destination_addr, ip_addr2a(&rcv->dst_ip), rcv->dst_port);
-
- if (body->data_coding == SMPP_CODING_UCS2)
- p += sprintf(p, "Content-Type: text/plain; charset=UTF-16\r\n");
- else
- p += sprintf(p, "Content-Type: text/plain\r\n");
+ p += sprintf(p, "Content-Type:text/plain\r\n");
str hdr_str;
hdr_str.s = hdrs;
@@ -1163,20 +1232,9 @@
dst_str.len = strlen(dst);
str body_str;
- if (body->data_coding == SMPP_CODING_UCS2) {
- memset(sms_body,0,280);
-
- LM_INFO("AAAA - received UCS2 encoding of length %d \n",body->sm_length);
- string2hex((unsigned char *)body->short_message,
- body->sm_length,sms_body);
-
- body_str.s = sms_body;
- body_str.len = strlen(sms_body);
- LM_INFO("AAAA - created hex encoding of length %d \n",body_str.len);
- } else {
- body_str.s = body->short_message;
- body_str.len = body->sm_length;
- }
+ body_str.len = convert_gsm7_to_utf8((unsigned char *)body->short_message,
+ body->sm_length,sms_body);
+ body_str.s = sms_body;
tmb.t_request(&msg_type, /* Type of the message */
&dst_str, /* Request-URI */
diff --git a/modules/proto_smpp/smpp.h b/modules/proto_smpp/smpp.h
index cf23fbc93c..7f12efafd4 100644
--- a/modules/proto_smpp/smpp.h
+++ b/modules/proto_smpp/smpp.h
@@ -131,6 +131,7 @@ typedef struct smpp_optional{
#define MAX_SCHEDULE_DELIVERY_LEN 1
#define MAX_VALIDITY_PERIOD 1
#define MAX_MESSAGE_ID 65
+#define MAX_SMS_CHARACTERS 254
typedef struct {
char system_id[MAX_SYSTEM_ID_LEN];
@@ -174,7 +175,7 @@ typedef struct {
uint8_t data_coding;
uint8_t sm_default_msg_id;
uint8_t sm_length;
- char short_message[254];
+ char short_message[MAX_SMS_CHARACTERS];
} smpp_submit_sm_t;
typedef struct {
Then simply use a new tar ball - the patch is not supposed to apply on a 3.0.1 release, but on the latest 3.0 branch.
johandeclercqdemocon
commented
4 years ago Razvan, I just upgraded my entire platform last Friday. If I just take the entire module from the master branch and put that on my 3.0.1 of last friday, will that work ?
Op wo 15 jan. 2020 om 09:07 schreef Răzvan Crainea <notifications@github.com
:
Then simply use a new tar ball https://github.com/OpenSIPS/opensips/archive/3.0.zip - the patch is not supposed to apply on a 3.0.1 release, but on the latest 3.0 branch.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/OpenSIPS/opensips/issues/1935?email_source=notifications&email_token=AKDSPWOSFCAYCP7CBHDRZ5DQ5273VA5CNFSM4KFFUZX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI7NNZY#issuecomment-574543591, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKDSPWLS5LS3RZSHXQZBQTTQ5273VANCNFSM4KFFUZXQ .
razvancrainea
commented
4 years ago @johandeclercqdemocon I believe it should be fine, I've just ran a quick test and it works OK.
johandeclercqdemocon
commented
4 years ago the master branch for proto_smpp works on 3.0.1.
@ works.
but there is still a problem with decoding.
we have sent Réunion. As you can see below, é is not properly decoded. Below is the output on log_level 5 and attached is the pcap.
Jan 17 08:38:04 hendrix /data/opensips/sbin/opensips[2834]: DBG:proto_smpp:handle_smpp_msg: Received SMPP command 00000005 Jan 17 08:38:04 hendrix /data/opensips/sbin/opensips[2834]: DBG:proto_smpp:handle_deliver_sm_cmd: Received deliver_sm command Jan 17 08:38:04 hendrix /data/opensips/sbin/opensips[2834]: DBG:proto_smpp:handle_submit_or_deliver_cmd: Received SMPP message#012FROM:#01101 01 33630545022#012TO:#01101 01 33757936423#012LEN:#0117#012R#005union
On 15.01.20 09:07, Răzvan Crainea wrote:
Then simply use a new tar ball https://github.com/OpenSIPS/opensips/archive/3.0.zip - the patch is not supposed to apply on a 3.0.1 release, but on the latest 3.0 branch.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/OpenSIPS/opensips/issues/1935?email_source=notifications&email_token=AKDSPWOSFCAYCP7CBHDRZ5DQ5273VA5CNFSM4KFFUZX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI7NNZY#issuecomment-574543591, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKDSPWLS5LS3RZSHXQZBQTTQ5273VANCNFSM4KFFUZXQ.
johandeclercqdemocon
commented
4 years ago johandeclercqdemocon
commented
4 years ago sending a message to the provider is also a problem.
Route[0]: MESSAGE is coming in from A: xxx to B: yyy we call route[message], rb Test4
DBG:core:decode_mime_type: Decoding MIME type for:[text/plain] Jan 17 10:32:10 hendrix /data/opensips/sbin/opensips[21996]: DBG:proto_smpp:send_submit_or_deliver_request: FROM: xxx DBG:proto_smpp:send_submit_or_deliver_request: TO: yyy DBG:proto_smpp:send_submit_or_deliver_request: MESSAGE: Test4 type = 65537 ERROR:proto_smpp:hex2int: 'T' is no hex char ERROR:proto_smpp:hex2int: 's' is no hex char ERROR:proto_smpp:hex2int: 't' is no hex char
is there a problem with the message received ?
razvancrainea
commented
4 years ago Most likely is the "reversed" problem, converting from UTF-8 to GSM7. This is not yet implemented.
johandeclercqdemocon
commented
4 years ago ok, then for the moment for that direction I will continue with lua function. Can you please let me know when you have the reverse implemented ?
Thanks and best regards, Johan.
razvancrainea
commented
4 years ago Sure, will update the ticket as soon as the conversion is done.
johandeclercqdemocon
commented
4 years ago Hello we got our lua right. But add_body_part seems to interpret the string or this is something wrong in my call :
part of script.
$avp(msg)= $rb;
$avp(tool) = "encode";
$avp(format) = "GSM";
#$avp(formatted-msg)="";
if(lua_exec("arg_function"))
{
xlog("encode body to GSM~> [$avp(formatted-msg)]\n");
}
if ($avp(formatted-msg)!=NULL and $avp(formatted-msg)!='' and $avp(formatted-msg)!='<null>')
{
remove_body_part("text/plain");
add_body_part("$avp(formatted-msg)", "text/plain;");
xlog("the call goes to provider , we have translated the body to GSM7bit => message body rb $rb");
}log level 5 - log.
siplua: encode:GSM:Réunion
DBG:core:sig_usr: SIGCHLD received from 26168 (status=0), ignoring
siplua: Formated GSM-7 bit string ~> 5205756e696f6e
DBG:core:__search_avp_map: looking for [formatted-msg] avp - found 12
DBG:core:pv_printf: final buffer length 72
encode body to GSM~> [5205756e696f6e]
DBG:core:comp_scriptvar: str 29 : 5205756e696f6e
DBG:core:comp_scriptvar: str 29 : 5205756e696f6e
DBG:core:parse_headers: flags=ffffffffffffffff
DBG:core:decode_mime_type: Decoding MIME type for:[text/plain]
DBG:core:pv_printf: final buffer length 14
DBG:core:add_body_part: adding mime <text/plain;>, hdrs <>, body=<5205756e696f6e>
DBG:core:parse_headers: flags=ffffffffffffffff
DBG:core:pv_printf: final buffer length 124
the call goes to provider, we have translated the body to GSM7bit => message body rb RéunionCan you pleae explain what I do wrong here ?
razvancrainea
commented
4 years ago The $rb variable always prints the body of the initial message (the GSM7 encoding), not the output of lua. However, the body seems to be ok, and you can confirm by double checking a PCAP.
johandeclercqdemocon
commented
4 years ago I will send you one at noon. you will see that it is the original body.
Op di 21 jan. 2020 om 09:17 schreef Răzvan Crainea <notifications@github.com
:
The $rb variable always prints the body of the initial message (the GSM7 encoding), not the output of lua. However, the body seems to be ok, and you can confirm by double checking a PCAP.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenSIPS/opensips/issues/1935?email_source=notifications&email_token=AKDSPWPZMSZFXPZRTYFEFILQ62VRDA5CNFSM4KFFUZX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJO3U7Q#issuecomment-576567934, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKDSPWIQSZEWEGEI6D4ZPGTQ62VRDANCNFSM4KFFUZXQ .
johandeclercqdemocon
commented
4 years ago so is there then another way in which way I can inspect what is in the modified body of the message ?
Op di 21 jan. 2020 om 09:17 schreef Răzvan Crainea <notifications@github.com
:
The $rb variable always prints the body of the initial message (the GSM7 encoding), not the output of lua. However, the body seems to be ok, and you can confirm by double checking a PCAP.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenSIPS/opensips/issues/1935?email_source=notifications&email_token=AKDSPWPZMSZFXPZRTYFEFILQ62VRDA5CNFSM4KFFUZX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJO3U7Q#issuecomment-576567934, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKDSPWIQSZEWEGEI6D4ZPGTQ62VRDANCNFSM4KFFUZXQ .
razvancrainea
commented
4 years ago I've just found some time to implement this. I've pushed it into master, but I won't backport it yet, as it relies on some changes that are only on master. Please give it a try and if there are any problems, get back here. Otherwise please close this ticket.
johandeclercqdemocon
commented
4 years ago Just proto-smpp from master is enough for testing?
Outlook voor iOShttps://aka.ms/o0ukef downloaden
Van: Răzvan Crainea notifications@github.com Verzonden: dinsdag, januari 21, 2020 12:42 PM Aan: OpenSIPS/opensips CC: johandeclercqdemocon; Mention Onderwerp: Re: [OpenSIPS/opensips] [BUG] tcp reads buffer correctly for smpp but when reading the body, it drops the part after 0x00 character. (#1935)
I've just found some time to implement this. I've pushed it into master, but I won't backport it yet, as it relies on some changes that are only on master. Please give it a try and if there are any problems, get back here. Otherwise please close this ticket.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OpenSIPS/opensips/issues/1935?email_source=notifications&email_token=AKDSPWJJ36QGRFEY36FRM7DQ63NS3A5CNFSM4KFFUZX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJPOOGQ#issuecomment-576644890, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKDSPWL22PGLZEQHSISFKUDQ63NS3ANCNFSM4KFFUZXQ.
johandeclercqdemocon
commented
4 years ago Secondly, do you want me to open another bug on my add-body-part question?
Outlook voor iOShttps://aka.ms/o0ukef downloaden
Van: Răzvan Crainea notifications@github.com Verzonden: dinsdag, januari 21, 2020 12:42 PM Aan: OpenSIPS/opensips CC: johandeclercqdemocon; Mention Onderwerp: Re: [OpenSIPS/opensips] [BUG] tcp reads buffer correctly for smpp but when reading the body, it drops the part after 0x00 character. (#1935)
I've just found some time to implement this. I've pushed it into master, but I won't backport it yet, as it relies on some changes that are only on master. Please give it a try and if there are any problems, get back here. Otherwise please close this ticket.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OpenSIPS/opensips/issues/1935?email_source=notifications&email_token=AKDSPWJJ36QGRFEY36FRM7DQ63NS3A5CNFSM4KFFUZX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJPOOGQ#issuecomment-576644890, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKDSPWL22PGLZEQHSISFKUDQ63NS3ANCNFSM4KFFUZXQ.
razvancrainea
commented
4 years ago Yes, just proto_smpp from master should be enough for testing.
Yes, as soon as you have a pcap for the add_body_part() issue, please open a new ticket.
johandeclercqdemocon
commented
4 years ago Ok I will open this evening. Reason that I insist is that by using lua, we can add a lot of flexibility.
Outlook voor iOShttps://aka.ms/o0ukef downloaden
Van: Răzvan Crainea notifications@github.com Verzonden: dinsdag, januari 21, 2020 12:48 PM Aan: OpenSIPS/opensips CC: johandeclercqdemocon; Mention Onderwerp: Re: [OpenSIPS/opensips] [BUG] tcp reads buffer correctly for smpp but when reading the body, it drops the part after 0x00 character. (#1935)
Yes, just proto_smpp from master should be enough for testing. Yes, as soon as you have a pcap for the add_body_part() issue, please open a new ticket.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OpenSIPS/opensips/issues/1935?email_source=notifications&email_token=AKDSPWLMA5N6GDPE6G4KXJLQ63OKXA5CNFSM4KFFUZX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJPO5DA#issuecomment-576646796, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKDSPWPSLQHVQ2K7A5ABYA3Q63OKXANCNFSM4KFFUZXQ.
volga629-1
commented
4 years ago Then simply use a new tar ball - the patch is not supposed to apply on a 3.0.1 release, but on the latest 3.0 branch.
@razvancrainea Is this zip already contain latest fixes ?
razvancrainea
commented
4 years ago No, those are only in master branch, and will not be backported.
johandeclercqdemocon
commented
4 years ago Hello,
upon further testing, I see that you do the encoding to gsm7 bit yourself. So there is no need anymore for the lua function.
There are however a few characters that are not properly encoded.
@ -> ¡ £ -> ? $ -> ¤ _ -> ? ¤ -> ? § -> O € -> ?
I have run this in lua
python3 /data/opensips/scripts/gsm_utf.py @1£1$1_1¤1§1€1 encode GSM
b'00
python3 /data/opensips/scripts/gsm_utf.py @£$_¤§€ encode GSM
b'000147534d245f1b65'Below the message with all special chars.
DBG:proto_smpp:send_submit_or_deliver_request: sending submit_sm
DBG:proto_smpp:send_submit_or_deliver_request: FROM: 33757936423
DBG:proto_smpp:send_submit_or_deliver_request: TO: 33630545022
DBG:proto_smpp:send_submit_or_deliver_request: MESSAGE: 1@£$¥¥èéùìòÇØøÅåΔ_ΦΓΛΩΠΨΣΘΞÆæßÉ!"#¤%&'()*+,-./:;<=>?¡ÄÖÑܧ¿äöñüà^{}\[~]|€2 type = 0
Attached the pcap.
Can you please check ? faultychars.zip
johandeclercqdemocon
commented
4 years ago bugfix is okay. Thank you for the help.
OpenSIPS version you are running
Describe the bug
Somebody sends an sms in smpp to opensips containing @. In GSM 7 bit this is 0x00. The message body send to the destination user contains only the part before @. Decoding GSM 7 bit we can do ourselves. The problem is that the body part is not correctly filled up.
You will find syslog below. Do note that tcp_conn gets the correct amount of bytes (59 is the lenght of the packet in the pcap also).
To Reproduce
Expected behavior The destination user should receive the entire body of the sms.
Relevant System Logs
OS/environment information
Additional context
If somebody could explain how to add debug logs for the relevant buffer fields in the functions that you can see in syslog, that would be a great start. syslog_and_pcap.zip