Timeout opening a socket with a SIM7600E-H with some providers only

[st31ny]

[x] I have read the Troubleshooting section of the ReadMe

What type of issues is this?

[ ] Request to support a new module [ ] Bug or problem compiling the library [x] Bug or issue with library functionality (ie, sending data over TCP/IP) [ ] Question or request for help

What are you working with?

Modem: SIMCOM SIM7600E-H SIM7600M22_V1.1 Main processor board: ESP32 TinyGSM version: 0.11.5 Code: MqttClient, adapted slightly

Scenario, steps to reproduce

I am testing with the MqttClient example with the three major network providers in the region (Germany: Telekom, Vodafone, O2/Telefonica). All have equally good LTE coverage at my place and I am using an external antenna.

I tested all SIM cards with my phone and used the same APN/username/password settings that actually worked with LTE on my phone.

The hardware itself covers almost all bands used by the providers here.

Expected result

Connection should work equally with all three providers.

Actual result

Connection works perfectly with Vodafone. After less than 20 s after boot the first MQTT packet is delivered successfully to the server.

With Telekom, the device can register in the network (AT+CGREG returns status 1 "registered"), open a GPRS connection (AT+NETOPEN returns 0) and even gets an IP address. So it seams that everything works just fine until I try to actually open a TCP stream. This always aborts with a timeout (AT+CIPOPEN returns error code 10 "timeout"). I even increased the default timeout of 15 s to 75 s without success. In the working case with Vodafone above, connecting to the server and doing the MQTT login handshake takes less than 400 ms.

With O2/Telefonica, I can still connect to the network (AT+CGREG returns status 1 "registered"), however, opening a GPRS connection fails (AT+NETOPEN returns ERROR).

Debug and AT command log

See log of my attempt with Telekom, redacted for privacy.

Do you have any ideas how I can debug this issue further? Thank you very much for your help.

[st31ny]

I have invested some time to debug the issue and actually got all three SIM cards working. However, I am not sure if I fully understand the problem.

1. Apparently, my issue has to do with the used PDP context identification cid that is fixed to "1" in the current implementation in in TinyGSM. Using my Telekom SIM I queried the actual set configuration using sendAT(GF("+CGDCONT?")); waitResponse();:

AT+CGDCONT?

+CGDCONT: 1,"IP","internet.telekom","0.0.0.0",0,0,0,0
+CGDCONT: 2,"IPV4V6","ims","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0
+CGDCONT: 3,"IPV4V6","","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,1

So, there seems to be an automatic second entry "ims" (which is used for VoLTE). I asked a Telekom technician to check for my connection and he confirmed that my device tries to send data using the "ims" APN.

2. When I set cid to "2" in TinyGSM's gprsConnectImpl() it immediately started working. However, a cid of "2" does not work anymore with my Vodafone SIM. I experimented with CGACT to disable all PDP contexts except one without success.

3. My next attempt was to delete the unnecessary PDP contexts. So I reverted TinyGSM to 0.11.5 and issued some extra AT commands before calling gprsConnect():

    modem.sendAT(GF("+CGDCONT=1"));
    modem.waitResponse();
    modem.sendAT(GF("+CGDCONT=2"));
    modem.waitResponse();
    modem.sendAT(GF("+CGDCONT=3"));
    modem.waitResponse();
    modem.gprsConnect("internet.telekom");

Afterwards, the Telekom SIM actually works, but not at the first attempt. So, I need to clear the PDP contexts, try to connect with gprsConnect() (which fails), call restart() (init() is not enough!) and then go through the entire connection setup process again. Only deletions seem to be affected by this quirk — changing an APN becomes effective immediately, without a restart().

---

Conclusions Based on my observation I come to these conclusions (which might be flawed or incomplete):

• For Telekom SIM, if a PDP context with cid==2 is present, it is used, no matter if it was deactivated with AT+CGACT.
• With a Telekom SIM, a PDP context with cid==2 with APN "ims" is created automatically. This APN is for VoLTE only and does not work for GPRS although connection is possible and an IP address is assigned.
• For Vodafone SIM, PDP context with cid==1 is always used, even if deactivated. I never got Vodafone working with cid==2.
• I didn't do the same intense testing with O2 but believe that it's similar to Telekom.
• The PDP context is stored persistently in the modem (not in the SIM, I tested with different Telekom/Vodafone SIMs and different modems) and sometimes (?) updated when adding a new SIM.
• By deleting the PDP context with cid==2, Telekom (and presumably O2) can be forced to use the PDP context with cid==1.
• The deletion of a PDP context only takes effect after calling restart().

---

Workaround This is my current workaround that I can implement solely in application code (no change to TinyGSM itself required):

• Use modem.restart("1234") instead of modem.init("1234").
• Call modem.setNetworkMode() and modem.waitForNetwork() as usual.
• Delete all PDP contexts by calling modem.sendAT("+CGDCONT={cid}"); modem.waitResponse(); for all relevant cid (I call it for 1 to 24, including).
• Try to connect to GPRS as usual by calling modem.gprsConnect(). If that fails, go back to the beginning (i.e., start over with a modem.restart()).

---

While I have a functioning workaround, this behavior is a bit bewildering — and I have no idea how this could be hacked into TinyGSM itself reasonably. I might have missed a crucial point; maybe somebody can explain better what's going on.

If I can help to investigate this any further, please let me know!

[star297]

Using SIM7600E and have a problem only with O2 throughout Germany similar to what you are saying. We use EMnify SIM cards and block O2 before using them. We don't stream data as such only use MQTT functions via PubSub Client. Other operators work faultlessly. Perhaps O2 don't like these modems and only want real mobile phone customers ?

[st31ny]

Perhaps O2 don't like these modems and only want real mobile phone customers ?

That is a good question. Personally, I have no experience with EMnify SIM cards as I only tried regular cards (including from Drillisch that use the O2 net, too). What does the log say? So, up to which state can you bootstrap? Have you applied my workaround above?

[star297]

I will add your workaround and see what happens and report back with the result. The problem is this extends the connection time which results in us not being able to contact the device. But may be the only way.

[st31ny]

I will add your workaround and see what happens and report back with the result. The problem is this extends the connection time which results in us not being able to contact the device. But may be the only way.

Sounds good. That's true, the workaround really delays the initial connection. I am still below 1 min, though. Fortunately, for my application, this doesn't matter as the device is usually permanently connected to the power grid.