Thanks Alex.
I tested your patch and it works fine.
Regards,
Matti
Alexander Malysh wrote:
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
