No connection to TCP Socket

Hi all,

after investigating on this topic for more than 2 weeks I found no solution so far and I hope that someone here may push me into the right direction.

For a better understanding let me figure out the use case - although you may skip this section :wink:

We operate devices inside a closed private mobile network (10.x.x.x) with no connection to the internet. Each device implements a TCP client socket for connection to a centralized server socket (port 56893) receiving notifications, a TCP Server socket on port 56891 that allows different clients to connect to the devices on demand (for settings/state/etc) and a FTP client for automatic device firmware and modem software update using a private network internal FTP server.

Up to now we used SL8082 devices with an OpenAT Software package using GSM/Edge or UMTS transfer mode. Since we need to switch to LTE transfer mode, we will use WP76xx modems for our new design.

My current software package is built on LEGATO 19.11.5 and the following topics work out fine:

  • connection to the TCP socket over LTE
  • connection to the FTP server over LTE (using curl)

The TCP server socket (port 56891) is not accessible from any client via LTE (rmnet_data0) interface. I verified these points:

  • IPTABLES has been disabled (using -F or -I INPUT -j ACCEPT)
  • binding the socket to the private network adress ( or binding to makes no difference
  • netstat shows my app as active TCP listener on the listen port 56891; either bound to or the private network IP depending on the bind address selected (see above)
  • running the application in sandboxed or non-sandboxed mode makes no difference
  • any other device inside the private network 10.x.x.x may ping the device using successfully ! If trying to connect via telnet the client gets a “rejected” error
  • any client running on the module itself may connect to the socket using any IP address (, or; therefore the TCP socket is fully functional
  • any client running on the hosting windows machine may connect to the TCP server using; therefore the TCP socket is accessible via network by clients outside from the module
  • I tested the clients with existing SL8082 Server Sockets successfully to exclude a client issue
  • I tested the application with the radio rat forced to GSM to exclude a mobile network issue with LTE connections

After all these tests I’ve ot no more idea to find out, why this is not working. Something seems to block any inbound connection via the rmnet_data0 interface to my application code. The other interfaces (local and indeed will not be blocked.

I heard about SMACK, but I found no explicit correlation to my TCP server socket problem. I think it is strange, that any inbound connection attempt via rmnet_data0 fails, whereas any outbound connection works fine.

I would be glad to read some ideas, comments or further steps for analyzing this problem.

Best regards, Heino

PS: after finishing this … may be the port range (> 32767) causes the problem ? I will test this soon …

Seems you are using private ip address.
Have you tried with a sim card with public ip address?

Hi jyijyi,

yes off course, all IP addresses assigned in this private network are addresses - this is the nature of a closed private network. There’s no way to operate SIM cards with an ip outside this range inside this network, since no access to the outside world is allowed.

Please note: Currently we operate about 5400 devices with Q2686 and SL8082 modules which must be replaced by G4 capable WP76 modules. Q2686 and SL8082 with OpenAT software operate as TCP servers using addresses without any issues. In addition the WP76xx module may connect to any of these TCP servers using a ip itself.

Therefore there should be no blocking of addresses for inbound connections. If this is the case, this limitation must be removed from the legato framework - or must be configurable at least.

Best regards, Heino

Maybe capturing a wireshark log and see if there is any hints

Thanks for this advice. I started capturing the ethernet data this morning, but I’m still not in the drivers seat to interpret my captures completely; at least I saw plenty of IPV6 telegrams and I guess, the problem may be implicit IPV6 over IPV4 communicaion between the server and the client which may cause my problem. I will continue testing tomorrow and will get back here.

Best regards

Sorry for comming back that late.

Using tcpdump I see, that the rmnet_data0 interface doesn’t show any incomming IP traffic, if trying to connect to the open 56891 port via the remote IP ( in my case), whereas I see the expected traffic

  • if pinging the IP
  • connecting to other devices (like FTP) inside the private network

tcpdump was started with “./tcpdump -i any port not 22 and port not 50817”, which displays any traffic on any interface except for my SSH connection ports. In addition I tried monitoring the remote port only using “./tcpdump -i rmnet_data0” also with same results.

So, if tcpdump shows absolutely no traffic during connection attempts to my opened port: am I sure, that the network provider inhibits any connection attempty to my port ? Are there any other circumstances that prevent tcpdump from showing incoming traffic ? Are there any other tests I can run to ensure this ?

What makes me unsafe to believe in this: attempting to connect to other devices with SL8082/WP86 modules succeeds always; these device are always accessible, if connecting to their open port 56891.

Any help apreciated and best regards, Heino

have you tried to open other port like port 80, 21 instead of 56891?

Tried port 80 for my application, but no success.

I think, tcpdump should show me any access to my IP regardless, if there’s an open port or not; i.e. tcpdump should display an incoming TCP telegram if trying to connect to regardless of an active listener on port 12345. Is this true or is there any other way to detect incoming traffic ?

You can see if this is true when capturing wireshark on usb ecm interface

Yes, on the ecm USB interface I can see all connection attempta to this port. If the rmnet_data0 interface is functional exactly the same, this means, that all incomming traffic to the interface rmnet_data0 - except for ICMP - is blocked by the provider.

If there’s no more room for other tests, I will contact the provider (vodafone) for support.

Finally all TCP ports are visible if leaving the module for more than 24 hours registered to the network. Thanks for any support !

Regards, Heino