Two more issues found

apmyp · Post by **apmyp** » Mon Apr 23, 2007 10:06 am

Me again

Thanks for the previous fix.
I found that client forces disconnect on messages with Reply Path flag set, e.g. when esm_class is 0xc0 or 0x40.
Another thing is that service_type parameter is set to the same value as system_type.

Post by **alt** » Mon Apr 23, 2007 1:32 pm

Could you send me a hex dump of such message?

Second issue will be fixed in the next version.

apmyp · Post by **apmyp** » Mon Apr 23, 2007 3:48 pm

Sorry, there was a mistake in first post, when I wrote about esm_class being equal to 0x40, it should read 0x80 of course.
Here's am example of pdu causing disconnect
0000003500000005000000000ec9804c00010131323334343335363738390002013335333500800000000000000100053132333435

command_length: 00 00 00 35
command_id: 00 00 00 05
command_status: 00 00 00 00
sequence_number: 0e c9 80 4c
service_type: 00
source_addr_ton: 01
source_addr_npi: 01
source_addr: 31 32 33 34 34 33 35 36 37 38 39 00
dest_addr_ton: 02
dest_addr_npi: 01
destination_addr: 33 35 33 35 00
esm_class: 80
protocol_id: 00
priority_flag: 00
schedule_delivery_time: 00
validity_period: 00
registered_delivery: 00
replace_if_present_flag: 00
data_coding: 01
sm_default_msg_id: 00
sm_length: 05
short_message: 31 32 33 34 35

When this pdu is sent from SMSC, the client raises evReceived message, and then disconnects.
Though I'm not sure this particular pdu is correct, as I suspect that when Reply Path is set, some additional info must be present in short_message, but I guess disconnection is not expected anyway in this case.
Same happens, when esm_class is 0xc0, i.e. both UDHI and Reply Path bits are set. I will post hex dump for that case later.

Post by **alt** » Mon Apr 23, 2007 4:46 pm

It looks like ordinary SMS message.
Can you check if client raises evDeliverSm and evSendData events after evReceiveData event?

apmyp · Post by **apmyp** » Mon Apr 23, 2007 8:00 pm

I checked once again, pdu above was ok.
So I tried another one:
0000004600000005000000000000000400010131323334353230313938350002013335333500c000000000000001001630353041303330303035303439363431363944313039

and here's log from smppclientdemo

SmppClient connected
Binding SmppClient for SystemId: test
Sending Data: 0000001f000000090000000056d1d1c674657374000065736d650034000000
SmppClient bound
Bind result : sytem is theSMSC with status ESME_ROK
Received Data: 0000001d800000090000000056d1d1c6746865534d5343000210000134
Received Data: 0000004600000005000000000000000400010131323334353230313938350002013335333500c000000000000001001630353041303330303035303439363431363944313039
evDisconnect

I'll try to get more of the same kind

Post by **alt** » Mon Apr 23, 2007 10:52 pm

Strange, this pdu has both UDHI and Reply Path flags, but User Data Header
has incorrect UDHL length = 30 (48 dec).
What do you expect in this user data?

apmyp · Post by **apmyp** » Tue Apr 24, 2007 8:57 am

Yes, obviously the udh part is not correct. At the first sight I noticed that there's correlation with disconnections and messages with udhi and reply path set, and didn't dig much into udh part of the message. But now I see that they're not correct.
It puzzles me a bit, because I take those from real smsc logs.
Will try to sort out similar messages and see what's wrong with them.
Yet, one would rather expect error reported on such a message, than a disconnect.
Anyway, thanks for your time.
Once again, you're doing a great job

Post by **alt** » Wed Apr 25, 2007 11:54 am

I've released version 1.2.2
I hope I solved these two issues.