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 ...

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 ...

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 ...

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.

thanks.
going to check new version.

Hi there

First of all wanted to say thanks for great job.

Next, I've tried to run your demo app against SCTT smsc simulator and noticed following error. The simulator has an option to execute commands in cmds.conf and there is possibility to originate unsolicited AlertNotification PDUs in order to ...