Introduction
In some cases, a node may appear reachable (successful ping) but still fail to establish TCP connections on required service ports such as 2775 (SMPP) or 1035 (UCP).
Typical symptoms include:
-
Remote systems can ping the SMSC host, but telnet or application connections to SMSC ports fail with timeouts.
-
pcap captures show TCP SYN packets received but no SYN-ACK responses.
-
System logs or
netstat
/ss
output show no application listeners on the expected ports. -
Error messages in logs, for example:
TRAP6.TEXTPASS-FXFER-MIB::serverSessionStopped TEXTPASS-FXFER-MIB::fxferClientIpAddress.0 = IpAddress: 10.33.21.72
-
Running
systemctl status iptables
shows the service is inactive (dead).
Problem
A possible cause is that iptables (the firewall service) is not running (potentially after a system reboot.) While firewalld
may still be active, the iptables rules that allow ports (e.g., 2775, 1035) were not applied, leaving the ports inaccessible.
As a result:
-
Even though textpass and it's related processes are up and configured, no process are listening on the required ports.
-
Remote systems attempting to connect receive no response, resulting in what appears to be a complete outage.
You can verify this by running systemctl status iptables
which may show the service as inactive (dead).
Solution
To resolve the issue:
-
Start iptables manually (if not running):
sudo systemctl start iptables
-
Verify that iptables is running:
sudo systemctl status iptables
-
Enable iptables to start automatically at boot:
sudo systemctl enable iptables sudo systemctl is-enabled iptables # Expected output: enabled
-
Confirm required SMSC ports (2775, 1035, etc.) are open:
ss -lntp | egrep ':2775|:1035'
-
Validate remote connectivity by retrying SMSC binding or telnet from external systems.
Note
It is critical to ensure iptables is enabled to start at boot, otherwise the SMSC environment will experience similar outages after future reboots.
Matthew Mrosko
Comments