Overview

This article explains how to solve an outage related to SMPP applications that are unable to bind a specific TCP port(s) (configured as an outside listener).

Solution

1. Test the connection to the specific port (e.g., let us consider 1035), and ensure that it is in LISTEN mode.
   
   

   # netstat -na | grep 1035

   
   Output:
   
   

   tcp 0 0 0.0.0.0:1035 0.0.0.0:* LISTEN

2. Test the remote connection to the specific port:

   1. [root@remote_host ~]# curl -v telnet://111.222.333.444:1035

      
      Output:
      
      

      * About to connect() to 111.222.333.444 port 1035 (#0) * Trying 111.222.333.444... ^C

   2. [root@remote_host ~]# curl -v telnet://localhost:1035

      
      Output:
      
      

      * About to connect() to localhost port 1035 (#0) * Trying ::1... Connection refused * Trying 127.0.0.1... ^C

3. Test the connection to a different port to check if it is successful, e.g., 2775:
   
   

   [root@remote_host ~]# curl -v telnet://localhost:2775

   
   Output:
   
   

   * About to connect() to localhost port 2775 (#0) * Trying ::1... Connection refused * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 2775 (#0)

4. Check the iptables service, searching for a rule for the specific port:
   
   

   # more /etc/sysconfig/iptables

   
   Output:
   
   

   # Generated by iptables-save v1.4.7 on Thu Apr 12 16:11:26 2018 *filter :INPUT ACCEPT [36649:5176755] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [34046:3605072] -A INPUT -p tcp -m tcp --dport 1035 -j DROP* COMMIT # Completed on Thu Apr 12 16:11:26 2018

5. Check the iptables service in all RTRs:
   
   

   • [root@remote_host ~]# iptables -S

     
     Output:
     
     

     -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -p tcp -m tcp --dport 1035 -j DROP

     
     

   • [root@remote_host ~]# service iptables status

     
     Output:
     
     

     Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination 1 DROP tcp – 0.0.0.0/0 0.0.0.0/0 tcp dpt:1035 Chain FORWARD (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination

6. Identify at which run levels iptables would start or stop automatically.
   
   NOTE: The iptables service should not be set to start upon server reboot, as per standard Lithium deployment.
   
   

   [root@remote_host ~]# chkconfig --list iptables

   
   Output:
   
   

   iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off

   • If the iptables service is set to start, disable the service from starting up on the server reboot:
     
     

     [root@remote_host ~]# chkconfig iptables off

7. Comment out the -A INPUT -p tcp -m tcp --dport 1035 -j DROP line inside the /etc/sysconfig/iptables file.
8. Stop the iptables service:
   
   

   [root@remote_host ~]# service iptables stop

9. Check if the iptables service is active after the configuration changes and if there are no more rules to drop the messages:
   
   

   [root@remote_host ~]# service iptables status

   
   Output:
   
   

   Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination Chain FORWARD (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination

10. Stop the iptables service:
    

    [root@remote_host ~]# service iptables stop

    
    Output:
    
    

    iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Flushing firewall rules: [ OK ] iptables: Unloading modules: [ OK ]

    
    

11. Check that the iptables service is not running:
    

    [root@remote_host ~]# service iptables status

    
    Output:
    

    iptables: Firewall is not running.

     

Verification

Test the connection to the specified port again:

[root@remote_host ~]# curl -v telnet://localhost:1035

Output: