submit_sm_resp with non-zero status and body crashes connection
marcelog opened this issue · 9 comments
Hello,
We are receiving the following submit_sm_resp PDU when sending a message fails (hex dump):
00 00 00 21 - 80 00 00 04 - 00 00 00 0b -
00 00 00 02 - 30 41 30 30 - 30 30 30 30 -
41 33 44 33 - 32 33 41 31 - 00
Causing the following crash in the SMPP connection:
esme #PID<0.662.0>, unknown pdu: %SMPPEX.RawPdu{body: <<48, 65, 48, 48, 48, 48, 48, 48, 65, 51, 68, 51, 50, 51, 65, 49, 0>>, command_id: 2147483652, command_status: 11, sequence_number: 2}("Unexpected end of data"), stopping
What are your thoughts?
Thanks in advance.
EDIT: The body seems to contain the message id in an ASCIIZ string.
Hello!
As far as I can see, the first four 4-byte fields of the answer are 00 00 00 21, 80 00 00 04, 00 00 00 0b, 00 00 00 02.
They mean respectively: command length, command id, command status, sequence id.
So, we have a submit_sm_resp (command id 80 00 00 04) with status 00 00 00 0b. That means that we have negative SMSC answer with decimal error code 11.
SMPP 3.4 specification (page 67) states about this situation the following:
Note: The submit_sm_resp PDU Body is not returned if the command_status field contains a non-zero value.
On the other hand, in your example the submit_sm_resp pdu still has body (with message id "0A000000A3D323A1"). So, the parser crashes.
Hello @savonarola,
Thanks for your quick reply. So this is an invalid SMPP 3.4 PDU and it should not have a body at all?
On the other hand, SMPP 5.0 specification says:
Note: When a response PDU carries a non-NULL command_status field, it is indicating some form of error or rejection of the original request PDU. In such circumstances, a PDU body should not be included in the PDU and the command_length of the PDU should therefore be set to 16 (0x00000010). However some ESMEs or Message Centers may always include a PDU body regardless of the command_status being returned. In such circumstances, the receiving ESME or MC should ignore its contents, based on the knowledge that the original request failed. Ref. 4.7.6
Maybe you have to deal with such a strange SMSC.
I think it's a good idea to follow SMPP 5.0 advice and just drop all non-header data for negative resps so that the parser would be just a bit "more loyal".
I'll try to introduce such a patch shortly.
Great!
By the way: it would be nice if the content could be recovered and somehow accessed. In this case there's a message id that can later on be used to request support to the SMSC about the failure.
I have introduced a fix in issue-6 branch, see #7
I have also used your example for the corresponding test cases: https://github.com/savonarola/smppex/blob/issue-6/test/protocol_test.exs#L78
The logic is the following: the parser always tries to parse body for all resps. But if it fails, it ignores the failure for negative resps and returns only header info, as SMPP 5.0 advises.
Hello @savonarola,
Just did a quick test with the SMSC and the fix works perfectly, thank you very much for your quick response and patch, I really appreciate it :) Great work!
We can close this one as soon as you merge the patch I guess.
Best regards.
Published the fix as smppex 0.1.9 at hex.pm
Yes! Working with it already 👍 Thanks for your help!
The problem seems to be solved, so closing.
@marcelog thanks for the feedback.