The first problem encountered when an SMPP client is trying to connect to a SMPP server are BINDING issues. BIND failures could either happen on the TCP level or SMPP level (Application Level).
The first thing you have to check is, if you have TCP connectivity from your SMPP client towards the SMPP server. The basic TCP test is doing a telnet towards the SMPP server.
telnet <IP address or DNS address> <Port>
telnet copyndone.com 9000
The IP address or the DNS address with the corresponding port are basic informations provided to any SMPP client who wishes to connect to a SMPP server. If you are able to get in via telnet that means your TCP connection is established. However, if telnet fails (time out or connection refused), the next course of action is to identify where the TCP timeout fails or where the connection is getting refused. You might need to check first with your network team if the destination IP or DNS is open (including the port) from your local network. Imo, the quickest hint to verify if your local machine could get out of your local network towards the SMPP server IP or DNS address is by doing a traceroute.
traceroute <IP address or DNS address>
If you can see hops that would suggest that your passing thru ISP providers (and best if you are reaching the host network), that means its already open from your local network.. And you would then need to ask your SMPP server provider if they have opened your source IP for access. So this means you should be aware what is the public ip address you are using to connect.
Once TCP connection is verified as working, we are now ready to proceed with our SMPP client BIND. Any SMPP client who wishes to BIND to a SMPP server MUST use the BIND Parameters provided by SMPP server. Non compliance might result to BIND failure. So it is important to double check the SMPP BIND parameters you are using are valid.
At this point i would suggest that you refer to the SMPP specification for description of the different SMPP BIND parameters .e.g. BIND TON/NPI, System type, mode, service type, etc.
You can get a copy of SMPP spec form the link below (take smpp 3.4 as a most used example)
SMPP 3.4 Spec
Assuming your SMPP BIND is failing, normally your application log would tell you what is the error being returned by the SMPP server via the SMPP BIND response. However if you want to be specific and would want to see what is really happening. You can opt to run tcpdump from your client and restart the bind.
If you are running linux box you can try to execute
tcpdump -i <eth interface> -w <filename> host <client or server IP address or DNS address>
tcpdump -i eth0 -w bindproblem.cap host copyndone.com
* be aware that running a trace that listens to specific IP or host would also means capturing all the traffic to and from that host. So this means you should be familiar on how to identify the interesting traffic you want to check.
Once you have captured the trace you can open it using free tools like wireshark or ethereal. Now let us see how to read the trace
From the snippet of a SMPP BIND trasnceiver above you should be able to see all the paramters used by the SMPP client to bind to the SMPP server. So double check that you are using the correct parameters.
Your BIND request should always get a corresponding response from the SMPP server. To filter the traffic you can filter using the SMPP sequence id.
The error or reason of SMPP BIND failure (if there is) should be indicated on this packet. And you would need to correct this error if possible or use this info to report the problem to your SMPP server provider.