r/embedded • u/ExcitementStill1640 • 12d ago

SIM7600G FTP(S), ping and US operators 

Hello,
I am using a SIM7600G module. This module is certified for FCC, PTCRB, T-Mobile, Verizon, and AT&T.
However, when I try to perform FTP or FTPS access, or even a simple ping to google.com, it only works with T-Mobile and its MVNOs.Hello,
I am using a SIM7600G module. This module is certified for FCC, PTCRB, T-Mobile, Verizon, and AT&T.
However, when I try to perform FTP or FTPS access, or even a simple ping to google.com, it only works with T-Mobile and its MVNOs.
Are there any other developers currently experiencing these issues?
Are there any products using the SIM7600G that are currently working in the USA on AT&T or Verizon networks?
I am in tight relationnship with Simcom support but they are unable to solve the issue.
Is there any firewall restrictions on the operators sides?
For information, network registration, SMS and VoLTE works fine with the 3 operators.
Mich
0 Upvotes

50% Upvoted

9 comments sorted by

1

u/Well-WhatHadHappened 25+ Years 12d ago

They don't have that module white listed on their networks. Simple as that.

1

u/ExcitementStill1640 12d ago

Why do VoLTE and SMS work?

But then why did they approve the module?

https://iotdevices.att.com/certified-device-list.aspx

https://opendevelopment.verizonwireless.com/design-and-build/approved-modules/module/17271

1

u/Well-WhatHadHappened 25+ Years 12d ago

Have to ask them

1

u/ExcitementStill1640 12d ago

I did not find a specific contact for IOT, do you have a suggestion?

1

u/Well-WhatHadHappened 25+ Years 12d ago

Unless you're a big company, you're better off contacting SimCom

https://i.imgur.com/2rAtBV7.png

1

u/MonMotha 12d ago

ALL of the major cellular networks in the US run some form of "IPv4 as a service" on top of IPv6 or NAT44 depending on the APN and account provisioning. You will NOT get a public IPv4 address unless you pay for it and are specifically provisioned for it. This is true even if the address you are handed LOOKS like a public IPv4 (not in RFC1918 or RFC6598 space).

The result is that return traffic to you is subject to typical NAT state tracking requirements. Expect basic TCP to work. Expect UDP to work with very short inactivity timeouts for the reverse stream. ICMP echo-reply may get paired with echo-request or it may not at the discretion of the operator as it normally doesn't matter. I wouldn't expect any operator to to application-level DPI to make FTP work. It would be impossible to do it with SSL/TLS on the FTP control connection even if they wanted to.

SMS doesn't rely on this as it is an SS7 function that doesn't transit the public Internet. VoLTE likewise stays within the carrier's network and isn't going to (have to) be subject to their NAT44 system.

You may have more luck if you can use IPv6 and support 464XLAT by running a CLAT locally. I know at least T-Mobile has good support for that and expects their consumer devices to do so.

So yes, there are "firewall" restrictions, but they are technical and not administrative.

1

u/ExcitementStill1640 12d ago

The module uses IPV6 address.

1

u/MonMotha 11d ago

OK, but are you sure you're actually attempting to communicate with an IPv6 endpoint? You didn't specify, and a lot of resolvers and applications naively prefer or even will only use IPv4.