Session will be (automatically) destroyed when ShortMessageLength in SubmitSm PDU is too small
kbeholz opened this issue · comments
Hi,
recently we noticed the following case:
We received a SubmitSm PDU where everything was ok BUT the ShortMessageLength was set too small (while the command length was ok).
That caused that the Session was destroyed immediately.
We would have assumed that the Server might throw an Exception like an UnrecoverablePduException or a RecoverablePduException or anything like that so that we were at least able to send a response (rejection) to the message.
We are still running on the following version: 5.0.0 (2012-10-26). As I did not find any matching issue here we assume that this issue is still present in the current version. Could anyone please confirm this?
Example PDU for testing:
00000070000000040000000000000008000501414243444546000101303132333435363738393132000000000000010000003c6b61746265686f6c7a20667269656e646c792074657374206d65737361676520323a204772656574696e67732066726f6d205669656e6e61203a2d2900
(Command Length is 112 bytes, ShortMessageLength is set to 60 bytes while it is actually 61 bytes long due to the 0-byte at the end)
If anyone has an idea to handle this issue without changing the code base of the Cloudhopper, please let me know. Maybe there is any RuntimeException we did not notice so far but could catch in "our part" of the code.
Thanks in advance for your help.
Just wondering what you ended up doing? The library attempts to recover from bad data -- although it may think in this case that the session is hosed -- e.g. reading any further data from the socket would be dangerous. Was a real SMSC sending this?
Actually we did not change anything in the Server so far to handle such PDUs in a better way.
Seems like it did not happen again after we contacted our customer who was sending those PDUs and told them about the failure.