search

CDilshanMadusanka / smslib

Automatically exported from code.google.com/p/smslib
0 stars 0 forks source link

Message break in parts does not work as expected. #154

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
The File has a test multipart message which is Base64 encoded.SMSlib
indentifies this message as a single part message.Hence the last 8 bytes of
the message is getting lost.However when I add an extra dummy  byte to the
message then the encoding is proper.

The problem source is in the file attached.

SMSLib Version 3.2.2

Original issue reported on code.google.com by sushilgo...@gmail.com on 2 Dec 2008 at 5:07

Attachments:

GoogleCodeExporter commented 8 years ago 
Hello,

This is an old and unsupported version and yes this error did exist. There were 
some 
problems in the encoding routines of that version.

Please upgrade to the current version the soonest possible.

Original comment by T.Delenikas on 2 Dec 2008 at 7:29

GoogleCodeExporter commented 8 years ago 
I have tested again with v3.4 from the SVN and I get the same error.Attached is
another test example.

The issue persists only when using 7 bit encoding with port addressing.The 
attached
example is tested with both v3.4 and v3.2.2 and in both the cases the message 
is not
even detected as a multipart message.

Original comment by sushilgo...@gmail.com on 3 Dec 2008 at 8:14

Attachments:

GoogleCodeExporter commented 8 years ago 
Use this code instead of just printing the PDUs:

        List<String> pdus = msg.getPdus(smscNo, 123 );

        StringBuffer sb = new StringBuffer();
        for( String pdu  : pdus )
        {
            System.out.println( pdu );

            PduParser parser = new PduParser();

            Pdu pduObject = parser.parsePdu(pdu);
            sb.append(pduObject.getDecodedText());

            System.out.println(pduObject);

        }

        System.out.println();
        System.out.println(decodedMessage);        
        System.out.println(sb.toString());

And you will see all your data is still there.

Original comment by jjon...@gmail.com on 3 Dec 2008 at 9:11

GoogleCodeExporter commented 8 years ago

Original comment by T.Delenikas on 3 Dec 2008 at 9:12

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
The output is as follows:

04912143F571000C911989765722930000FFA00B0504000015B300037B0201D4B3F865B41A4BBEEE
C962F
05C8C06A5B7FC4A498531A37072303ABC06834121F9954F63EFCB7AF06ECFD69EE521741EBEC1DEB
0EA94
DD640E61E1A19C0D75CFABF8A21A4696E197CEB0309B13AB61F0199A39341BDDCE335D8DCDE79DF8
62762
90FC6E0C41B7359BF5BD1ECA92C164FBAA37626349FBC9A91C91A2E4C1F0657
=================================================
<< SmsSubmitPdu >>
Raw Pdu: 
04912143F571000C911989765722930000FFA00B0504000015B300037B0201D4B3F865B41A4BBEEE
C962F
05C8C06A5B7FC4A498531A37072303ABC06834121F9954F63EFCB7AF06ECFD69EE521741EBEC1DEB
0EA94
DD640E61E1A19C0D75CFABF8A21A4696E197CEB0309B13AB61F0199A39341BDDCE335D8DCDE79DF8
62762
90FC6E0C41B7359BF5BD1ECA92C164FBAA37626349FBC9A91C91A2E4C1F0657

SMSC Address: [Length: 4 (04) octets, Type: 81 (10000001), Address: 12345]
First Octet: 71 [TP-MTI: (SMS-SUBMIT), TP-RD: (allow duplicates), TP-VPF: 
(validity 
format, integer, TP-SRR: (Requests Status Report), TP-UDHI: (has UDH)]
Message Reference: 00
Destination Address: [Length: 12 (0C), Type: 91 (10010001), Address: 
919867752239]
TP-PID: 00 (00000000)
TP-DCS: 00 (7-bit GSM Alphabet) (00000000)
TP-VPF: 10584 hours

User Data Length: 160 (A0) septets
User Data (pdu) : 
0B0504000015B300037B0201D4B3F865B41A4BBEEEC962F05C8C06A5B7FC4A498531A37072303ABC
06834
121F9954F63EFCB7AF06ECFD69EE521741EBEC1DEB0EA94DD640E61E1A19C0D75CFABF8A21A4696E
197CE
B0309B13AB61F0199A39341BDDCE335D8DCDE79DF86276290FC6E0C41B7359BF5BD1ECA92C164FBA
A3762
6349FBC9A91C91A2E4C1F0657
User Data Header (pdu) : 0B0504000015B300037B0201
User Data Header Length: 11 (0B) octets

UDH Information Elements:
ConcatInformationElement[00, 03, 7B0201][MpRefNo: 123, MpMaxNo: 2, MpSeqNo: 1]
PortInformationElement[05, 04, 000015B3][Dst Port: 0, Src Port: 5555]

Non UDH Data (pdu)    : 
D4B3F865B41A4BBEEEC962F05C8C06A5B7FC4A498531A37072303ABC06834121F9954F63EFCB7AF0
6ECFD
69EE521741EBEC1DEB0EA94DD640E61E1A19C0D75CFABF8A21A4696E197CEB0309B13AB61F0199A3
9341B
DDCE335D8DCDE79DF86276290FC6E0C41B7359BF5BD1ECA92C164FBAA37626349FBC9A91C91A2E4C
1F065
7
Non UDH Data (decoded): 
[uYxKQU1I/wIEAgEQAR7y+JT0LQpdAQCWAAABd/yiXwKuAwvY5OeCPsa70o0USlMLC0aCrlPnsUxEj0d
2xKNa
BY9bj0p3hLCfFnNgtjXyyNxEYKrA1pD7LKuwVhlS21qInQvLPyIWfHI58atCA+]
=================================================

04912143F571000C911989765722930000FF1D0B0504000015B300037B0202289F48EB5C468B0683
C1603
01803
=================================================
<< SmsSubmitPdu >>
Raw Pdu: 
04912143F571000C911989765722930000FF1D0B0504000015B300037B0202289F48EB5C468B0683
C1603
01803

SMSC Address: [Length: 4 (04) octets, Type: 81 (10000001), Address: 12345]
First Octet: 71 [TP-MTI: (SMS-SUBMIT), TP-RD: (allow duplicates), TP-VPF: 
(validity 
format, integer, TP-SRR: (Requests Status Report), TP-UDHI: (has UDH)]
Message Reference: 00
Destination Address: [Length: 12 (0C), Type: 91 (10010001), Address: 
919867752239]
TP-PID: 00 (00000000)
TP-DCS: 00 (7-bit GSM Alphabet) (00000000)
TP-VPF: 10584 hours

User Data Length: 29 (1D) septets
User Data (pdu) : 0B0504000015B300037B0202289F48EB5C468B0683C160301803
User Data Header (pdu) : 0B0504000015B300037B0202
User Data Header Length: 11 (0B) octets

UDH Information Elements:
ConcatInformationElement[00, 03, 7B0202][MpRefNo: 123, MpMaxNo: 2, MpSeqNo: 2]
PortInformationElement[05, 04, 000015B3][Dst Port: 0, Src Port: 5555]

Non UDH Data (pdu)    : 289F48EB5C468B0683C160301803
Non UDH Data (decoded): [JOHVs24QAAAAAA1]
=================================================

uYxKQU1I/wIEAgEQAR7y+JT0LQpdAQCWAAABd/yiXwKuAwvY5OeCPsa70o0USlMLC0aCrlPnsUxEj0d2
xKNaB
Y9bj0p3hLCfFnNgtjXyyNxEYKrA1pD7LKuwVhlS21qInQvLPyIWfHI58atCA+JOHVs24QAAAAAA1
uYxKQU1I/wIEAgEQAR7y+JT0LQpdAQCWAAABd/yiXwKuAwvY5OeCPsa70o0USlMLC0aCrlPnsUxEj0d2
xKNaB
Y9bj0p3hLCfFnNgtjXyyNxEYKrA1pD7LKuwVhlS21qInQvLPyIWfHI58atCA+JOHVs24QAAAAAA1

As you can see from the last two lines, you data is still there.

Original comment by jjon...@gmail.com on 3 Dec 2008 at 9:17

GoogleCodeExporter commented 8 years ago 
Please try the message Below. 

uYxKQU1I/wIEAgEQAR7y+JT0LQpdAQCWAAABd/yiXwKuAwvY5OeCPsa70o0USlMLC0aCrlPnsUxEj0d2
xKNaBY9bj0p3hLCfFnNgtjXyyNxEYKrA1pD7LKuwVhlS21qInQvLPyIWfHI58atCA+JOHVs24QAAAAAA

When I try to send the above multi-part message, it displays only 1 message and 
the
last 8 bytes are missing

I think while sending 7 bit Multi-part SMS, care should be taken while 
splitting the
message. While splitting the message the last byte of the multi-part should not
contain part of the byte in the second part of the message. I think we have to
identify the boundary properly and left pad with 0 bits to make it work. Please 
confirm.

Original comment by sushilgo...@gmail.com on 3 Dec 2008 at 10:31

GoogleCodeExporter commented 8 years ago 
Confirmed using the new data you gave, will check this out.

Original comment by jjon...@gmail.com on 3 Dec 2008 at 11:02

GoogleCodeExporter commented 8 years ago 

I think the checkForConcat function needs a change. When I changed the function 
to
the following I am able to decode the message properly.

In my case, the text message length is exactly 160 characters (Excluding UDH) 
and in
the following condition gets true and therefore concatenation is not added

"if ((lengthOfText <= maxLengthWithUdh) || ((lengthOfText > maxLengthWithUdh) &&
(lengthOfText <= maxLength)))"

In the above scenario, the length of Text is 160, MaxLengthWithUdh will be 
always
less than 160, maxLength is 160 and it makes the condition to make it true.

If I replace the condition with "if (lengthOfText <= maxLengthWithUdh)" then it
works. Will it affect any other part of the message. Please clarify.

The Updated Function
--------------------
    protected void checkForConcat(Pdu pdu, int lengthOfText, int maxLength, int
maxLengthWithUdh, int mpRefNo, int partNo)
    {

        //if ((lengthOfText <= maxLengthWithUdh) || ((lengthOfText > maxLengthWithUdh) &&
(lengthOfText <= maxLength)))
        if (lengthOfText <= maxLengthWithUdh)           
        {
            // nothing needed
        }
        else
        {
            // need concat
            if (pdu.getConcatInfo() != null)
            {
                // if concatInfo is already present then just replace the values with the supplied
                pdu.getConcatInfo().setMpRefNo(mpRefNo);
                pdu.getConcatInfo().setMpSeqNo(partNo);
            }
            else
            {
                // add concat info with the specified mpRefNo, bogus maxSeqNo, and partNo
                // bogus maxSeqNo will be replaced once it is known in the later steps
                // this just needs to be added since its presence is needed to compute
                // the UDH length

                ConcatInformationElement concatInfo =
InformationElementFactory.generateConcatInfo(mpRefNo, partNo);
                pdu.addInformationElement(concatInfo);
                updateFirstOctet = true;
            }
        }
    }

Original comment by sushilgo...@gmail.com on 3 Dec 2008 at 11:10

GoogleCodeExporter commented 8 years ago

Original comment by T.Delenikas on 3 Dec 2008 at 12:55

GoogleCodeExporter commented 8 years ago 
yes, the change you suggest has a side-effect.  The reason the second condition 
exists is to prevent messages that can be single-part from becoming multi-part, 
e.g. 
a message that is 152 characters with port information should still be 1 part 
.. 
however, using your fix it will become multi-part.

The fix is not in the checkForConcat() itself but the value passed into the 
maxLength 
parameter from the 3 writeUDDataXXX() methods that call it.  Each of them 
specifies a 
maximum message length (160 for 7-bit, 140 for 8-bit and 70 for ucs2).  The bug 
is 
that these values make the assumption that there is no UDH present (for ported 
messages, this assumption is wrong).  To fix the problem we need to subtract 
the 
length of the existing udh from maxLength that is supplied.

I already implemented this and will be testing it shortly.  By the way, the 
recent 
fixes to the PDUUtils library are only in the 3.3.2 release and have not yet 
been 
merged into the 3.4 tree.  Thanks for finding this bug.

Original comment by jjon...@gmail.com on 3 Dec 2008 at 1:16

GoogleCodeExporter commented 8 years ago 
sushilgovind,

Jeff has already mentioned it.
If you wish to work with the repository, please checkout the "trunk" code and 
not the 
"branch". Jeff will commit the necessary changes in the trunk.

Apart from that, the branch (v3.4) is still a bit experimental and there is a 
chance 
you bump into other bugs as well.

Thanks :)

Original comment by T.Delenikas on 3 Dec 2008 at 1:26

GoogleCodeExporter commented 8 years ago 
Thanks Jeff for the feedback.Would you care to send me the patch after testing.

Original comment by sushilgo...@gmail.com on 3 Dec 2008 at 1:36

GoogleCodeExporter commented 8 years ago 
If you want to test it yourself here my updated PduGenerator.java

The changes are in:
protected void writeUDData7bit(Pdu pdu, int mpRefNo, int partNo) throws 
Exception
protected void writeUDData8bit(Pdu pdu, int mpRefNo, int partNo) throws 
Exception
protected void writeUDDataUCS2(Pdu pdu, int mpRefNo, int partNo) throws 
Exception

Original comment by jjon...@gmail.com on 3 Dec 2008 at 2:10

Attachments:

GoogleCodeExporter commented 8 years ago 
Thanks Jeff.Will test out.Im using smslib with a Fargo Maestro 100 modem.At 
times
when I try sending the sms I get CMS Error 512 but in the retry mode the 
message gets
delivered.Any idea why??

Original comment by sushilgo...@gmail.com on 3 Dec 2008 at 2:26

GoogleCodeExporter commented 8 years ago 
I added your patch and tested with the message below

uYxKQU1I/wIEAgEQAR7y+JT0LQpdAQCWAAABd/yiXwKuAwvY5OeCPsa70o0USlMLC0aCrlPnsUxEj0d2
xKNaBY9bj0p3hLCfFnNgtjXyyNxEYKrA1pD7LKuwVhlS21qInQvLPyIWfHI58atCA+JOHVs24QAAAAAA

and the results are 

part 1 :
uYxKQU1I/wIEAgEQAR7y+JT0LQpdAQCWAAABd/yiXwKuAwvY5OeCPsa70o0USlMLC0aCrlPnsUxEj0d2
xKNaBY9bj0p3hLCfFnNgtjXyyNxEYKrA1pD7LKuwVhlS21qInQvLPyIWfHI58atCA+JOHVs2

part 2 : JOHVs24QAAAAAA

Par 2 carried some extra bytes from part 1

Original comment by sushilgo...@gmail.com on 3 Dec 2008 at 3:37

GoogleCodeExporter commented 8 years ago 
Thats odd.  The tester code you gave results in the following with the fix:

=================================================
<< SmsSubmitPdu >>
Raw Pdu: 
04912143F571000C911989765722930000FFA00B0504000015B300037B0201D4B3F865B41A4BBEEE
C962F
05C8C06A5B7FC4A498531A37072303ABC06834121F9954F63EFCB7AF06ECFD69EE521741EBEC1DEB
0EA94
DD640E61E1A19C0D75CFABF8A21A4696E197CEB0309B13AB61F0199A39341BDDCE335D8DCDE79DF8
62762
90FC6E0C41B7359BF5BD1ECA92C164FBAA37626349FBC9A91C91A2E4C1F0657

SMSC Address: [Length: 4 (04) octets, Type: 81 (10000001), Address: 12345]
First Octet: 71 [TP-MTI: (SMS-SUBMIT), TP-RD: (allow duplicates), TP-VPF: 
(validity 
format, integer, TP-SRR: (Requests Status Report), TP-UDHI: (has UDH)]
Message Reference: 00
Destination Address: [Length: 12 (0C), Type: 91 (10010001), Address: 
919867752239]
TP-PID: 00 (00000000)
TP-DCS: 00 (7-bit GSM Alphabet) (00000000)
TP-VPF: 10584 hours

User Data Length: 160 (A0) septets
User Data (pdu) : 
0B0504000015B300037B0201D4B3F865B41A4BBEEEC962F05C8C06A5B7FC4A498531A37072303ABC
06834
121F9954F63EFCB7AF06ECFD69EE521741EBEC1DEB0EA94DD640E61E1A19C0D75CFABF8A21A4696E
197CE
B0309B13AB61F0199A39341BDDCE335D8DCDE79DF86276290FC6E0C41B7359BF5BD1ECA92C164FBA
A3762
6349FBC9A91C91A2E4C1F0657
User Data Header (pdu) : 0B0504000015B300037B0201
User Data Header Length: 11 (0B) octets

UDH Information Elements:
ConcatInformationElement[00, 03, 7B0201][MpRefNo: 123, MpMaxNo: 2, MpSeqNo: 1]
PortInformationElement[05, 04, 000015B3][Dst Port: 0, Src Port: 5555]

Non UDH Data (pdu)    : 
D4B3F865B41A4BBEEEC962F05C8C06A5B7FC4A498531A37072303ABC06834121F9954F63EFCB7AF0
6ECFD
69EE521741EBEC1DEB0EA94DD640E61E1A19C0D75CFABF8A21A4696E197CEB0309B13AB61F0199A3
9341B
DDCE335D8DCDE79DF86276290FC6E0C41B7359BF5BD1ECA92C164FBAA37626349FBC9A91C91A2E4C
1F065
7
Non UDH Data (decoded): 
[uYxKQU1I/wIEAgEQAR7y+JT0LQpdAQCWAAABd/yiXwKuAwvY5OeCPsa70o0USlMLC0aCrlPnsUxEj0d
2xKNa
BY9bj0p3hLCfFnNgtjXyyNxEYKrA1pD7LKuwVhlS21qInQvLPyIWfHI58atCA+]
=================================================

=================================================
<< SmsSubmitPdu >>
Raw Pdu: 
04912143F571000C911989765722930000FF1C0B0504000015B300037B0202289F48EB5C468B0683
C1603
008

SMSC Address: [Length: 4 (04) octets, Type: 81 (10000001), Address: 12345]
First Octet: 71 [TP-MTI: (SMS-SUBMIT), TP-RD: (allow duplicates), TP-VPF: 
(validity 
format, integer, TP-SRR: (Requests Status Report), TP-UDHI: (has UDH)]
Message Reference: 00
Destination Address: [Length: 12 (0C), Type: 91 (10010001), Address: 
919867752239]
TP-PID: 00 (00000000)
TP-DCS: 00 (7-bit GSM Alphabet) (00000000)
TP-VPF: 10584 hours

User Data Length: 28 (1C) septets
User Data (pdu) : 0B0504000015B300037B0202289F48EB5C468B0683C1603008
User Data Header (pdu) : 0B0504000015B300037B0202
User Data Header Length: 11 (0B) octets

UDH Information Elements:
ConcatInformationElement[00, 03, 7B0202][MpRefNo: 123, MpMaxNo: 2, MpSeqNo: 2]
PortInformationElement[05, 04, 000015B3][Dst Port: 0, Src Port: 5555]

Non UDH Data (pdu)    : 289F48EB5C468B0683C1603008
Non UDH Data (decoded): [JOHVs24QAAAAAA]
=================================================

Original comment by jjon...@gmail.com on 3 Dec 2008 at 4:01

GoogleCodeExporter commented 8 years ago 
sushilgovind, have you switched to version 3.3.2?????????

Original comment by T.Delenikas on 3 Dec 2008 at 7:03

GoogleCodeExporter commented 8 years ago 
yes I am currently testing with 3.3.2 version

Original comment by sushilgo...@gmail.com on 4 Dec 2008 at 2:17

GoogleCodeExporter commented 8 years ago 
Let me double check the patch.Maybe I have done something wrong

Original comment by sushilgo...@gmail.com on 4 Dec 2008 at 2:19

GoogleCodeExporter commented 8 years ago 
Sorry Jeff, You are right the patch does work and I was checking the wrong 
application.

Original comment by sushilgo...@gmail.com on 4 Dec 2008 at 4:36

GoogleCodeExporter commented 8 years ago 
r1576

Original comment by T.Delenikas on 5 Dec 2008 at 6:36

GoogleCodeExporter commented 8 years ago

Original comment by T.Delenikas on 23 Dec 2008 at 9:42