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
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 (10.0.22.219) or binding to 0.0.0.0 makes no difference
netstat shows my app as active TCP listener on the listen port 56891; either bound to 0.0.0.0 or the private network IP 10.0.22.219 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 10.0.22.219 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 (10.0.22.219, 127.0.0.1 or 192.168.2.2); therefore the TCP socket is fully functional
any client running on the hosting windows machine may connect to the TCP server using 192.168.2.2; 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 192.168.2.2) 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 ā¦
yes off course, all IP addresses assigned in this private network are 10.0.0.0/24 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 10.0.0.0/24 addresses without any issues. In addition the WP76xx module may connect to any of these TCP servers using a 10.0.0.0/24 ip itself.
Therefore there should be no blocking of 10.0.0.0/24 addresses for inbound connections. If this is the case, this limitation must be removed from the legato framework - or must be configurable at least.
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.
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 (10.0.22.219 in my case), whereas I see the expected traffic
if pinging the IP 10.0.22.219
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.
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 10.0.22.219:12345 regardless of an active listener on port 12345. Is this true or is there any other way to detect incoming traffic ?
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.
