Hi,
thanks for the bug report!
Unfortunately your patch is wrong. Please check attached patch that
fixes this issue.
This patch commited to CVS. Please retest with current CVS version.
Thanks,
Alex
Matti Ärmänen schrieb:
Hi,
here is a patch to fix the problem hopefully in the right place. The
len-parameter points to one byte too far, so obsolete data is taken into
the decode result. Attached is the patch related to the current
cvs-version of smsc_at.c v. 1.52
Attached are logs with (debug_fixed.log) and without the patch
(debug_bug.log).
We have used this successfully in production environment for some weeks.
Regards,
Matti
Matti Ärmänen wrote:
Hi,
I have analyzed this further and the problem seems to be in the
PDU-decoding of the smsc_at-module. In case of concatenated SMS:es it
leaves extra data at the end of the message. I think smsc_at is the
right place to fix it, so the patch is obsolete. This is in the latest
CVS-version and .
I investigate this further. The extra data at the end of last message
part varies, but at the end of other parts it is ü-character (0xC3 0xBC).
Regards, Matti
Alexander Malysh wrote:
Hi,
I don't see a reason for your patch. This seems to be some workaround
for a broken SMSC or SMSC module. Please provide us with more details:
1) which smsc module are you using?
2) the full debug log of at least one concatenated message with all
parts
3) what kannel version are you using?
Thanks,
Alex
Matti Ärmänen schrieb:
Hello,
in the cvs version there is the new functionality to concatenate the
incoming MO-messages. Without this patch there is ü-character (0xc3
0xbc) at the end of each part or some other character at the end of
the last part of the message. The attached patch removes these extra
characters so that the resulted message is the same as the
originally sent message.
The reference file is bb_smscconn.c version 1.98
Regards,
Matti Ärmänen
diff --git a/gw/smsc/smsc_at.c b/gw/smsc/smsc_at.c
index 98fb149..1a23ced 100644
--- a/gw/smsc/smsc_at.c
+++ b/gw/smsc/smsc_at.c
@@ -1887,7 +1887,7 @@ static Msg *at2_pdu_decode_deliver_sm(Octstr *data,
PrivAT2data *privdata)
stime = date_convert_universal(&mtime);
/* get data length
- * XXX: Is it allowed to have length = 0 ??? (alex)
+ * TODO: Is it allowed to have length = 0 ??? (alex)
*/
len = octstr_get_char(pdu, pos);
pos++;
@@ -1917,8 +1917,8 @@ static Msg *at2_pdu_decode_deliver_sm(Octstr *data,
PrivAT2data *privdata)
/* build the message */
message = msg_create(sms);
if (!dcs_to_fields(&message, dcs)) {
- /* XXX Should reject this message? */
- debug("bb.smsc.at2", 0, "AT2[%s]: Invalid DCS",
octstr_get_cstr(privdata->name));
+ /* TODO Should we reject this message? */
+ error("AT2[%s]: Invalid DCS (0x%02x)",
octstr_get_cstr(privdata->name), dcs);
dcs_to_fields(&message, 0);
}
@@ -1935,7 +1935,14 @@ static Msg *at2_pdu_decode_deliver_sm(Octstr *data,
PrivAT2data *privdata)
int nbits;
nbits = (udhlen + 1) * 8;
/* fill bits for UDH to septet boundary */
- offset = (((nbits / 7) + 1) * 7 - nbits) % 7;
+ offset = (((nbits / 7) + 1) * 7 - nbits) % 7;
+ /*
+ * Fix length because UDH data length is determined
+ * in septets if we are in GSM coding, otherwise it's in octets.
Adding 6
+ * will ensure that for an octet length of 0, we get septet length
0,
+ * and for octet length 1 we get septet length 2.
+ */
+ len = len + udhlen + 1 - (8 * (udhlen + 1) + 6) / 7;
}
at2_decode7bituncompressed(tmpstr, len, text, offset);
}
