Hi everyone,
I’m currently doing some tests with a Quectel EG915U-EU.
The module is on firmware EG915UEUABR03A01M08.
Could someone please send me:
The latest available firmware for the EG915U-EU
The firmware update procedure?
Thank you very much in advance! 
Nexus
I forgot to say that I need the new firmware to enable esim support
Dear Customer,
I have sent the latest firmware through email. Please check there.
Hello,
I’m currently experimenting with the Quectel EG915U-EU module. The voice functions have been working flawlessly for some time. Connecting to the provider’s network also works well. It only takes a few seconds to detect the home zone. After several attempts to establish a socket connection, the module no longer detects a home zone. Even a power cycle doesn’t help.
A different, new module works perfectly. But after several attempts to establish an internet connection, the same problem occurs. I suspect an invalid setting in the module’s NV-RAM area.
Is there a command to reset the module to factory settings? (<AT&F0> doesn’t work). The module has firmware version EG915UEUABR03A01M08. Could someone please send me the following: The latest available firmware for the EG915U-EU module. Which program do I need for the update? The procedure for updating the firmware?
Thank you very much for your efforts.
Helmut Stöckel
Dear Mr. Stöckel,
Thank you for the detailed description. Let me address your questions in turn.
Another thing, have you check the socket connection whether it already closed or not? Usually socket connection need to be closed first only can run different operation.
Here is how to diagnose and force-close. (This is for TCP) If you run on different operation such as MQTT, HTTP or others, please let me know.
Check which sockets are open
AT+QISTATE
This lists every active socket with its and socket state. Sockets lingering in an established or closing state that should already be gone would confirm the leak.
Force-close a single socket
AT+QICLOSE=,0
The second parameter is the timeout. By default the module waits up to 10 s for the FIN ACK from the remote peer before closing gracefully — and if the peer never responds (typical for a half-dead connection), it waits the full timeout. Setting the timeout to 0 forces an immediate close without waiting for the peer.
Example: AT+QICLOSE=0,0 closes socket 0 immediately.
For SSL sockets, use AT+QSSLCLOSE=,0 (0 = immediate execution).
If QICLOSE hangs, or to clear everything at once
Deactivating the PDP context tears down all sockets bound to it in one step:
AT+QIDEACT=
Then re-activate with AT+QIACT= when data is next required. As a last resort, cycling the protocol stack with AT+CFUN=0 followed by AT+CFUN=1 fully resets it without a hardware reboot.
The durable fix
Forcing closes manually only treats the symptom. The lasting fix is to ensure your application calls AT+QICLOSE for every socket it opens, including on its error and timeout paths — that is usually where the leak originates. I would also recommend enabling the close URC so your code is notified when a socket drops and can free the slot rather than reuse a dead one:
If this matches your observations, a firmware re-flash should not be necessary, since the socket table clears on every reboot.
Hello fazrulredzuan, I found the problem. To test a socket connection, I entered the APN and username using “AT+QICSGP” (contextID=1). The entries were apparently incorrect. This caused the module to not connect to the provider as before. That is, the “HOME ZONE” message at module startup either didn’t appear or only appeared sporadically. This disrupted a normal voice connection. After deleting the entries with “”, everything was working again. Now I only use contextID=2 for data connections. So far, an additional data connection works even without specifying an APN, username, and password. I haven’t yet been able to determine if this is the case with all providers. Thank you very much for your help! Best regards, Helmut
Dear Mr. Stöckel,
Thank you for the update and good work tracking it down. Your diagnosis is correct, and the behaviour you saw makes complete sense.
Why it disrupted registration and voice:
Context 1 is the primary PDP context the module uses for the initial LTE attach. If that context carries a wrong APN or an authentication setting that does not match the network can reject the attach. That in turn breaks registration, which is why the HOME ZONE indication failed to appear (or appeared only sporadically) and why the normal voice connection was disrupted. Clearing context 1 restored the correct attach behaviour, exactly as you observed.
One subtle point worth checking for the future: a frequent cause of this kind of reject is a mismatch in the authentication parameter rather than the APN string itself. When the username and password are empty, the authentication type in AT+QICSGP should be 0 (None). Setting it to PAP or CHAP with empty credentials can cause a reject even when the APN looks correct.
On using context 2 without an APN:
Your caution here is well founded. Some networks accept a blank APN and assign their default APN during the attach, which is why an additional data connection currently works for you without specifying one. However, this is provider- and SIM-dependent. Many MVNO, IoT, and roaming SIMs require an explicit APN and sometimes username/password and the matching authentication type. So I would not rely on the blank-APN behaviour across all providers. For production use, I recommend configuring context 2 with the correct APN and authentication for each operator you intend to support, and verifying the result.
Two practical notes:
Hello fazrulredzuan,
Thank you very much for the additional helpful information. I think it should work now.
Sincerely, H. Stöckel
I am also looking for the latest firmware for EG915U-EU. Could you share? Need AT commands, MQTT ,TLS .without PYTHON
I have sent you a follow up email to your email address, kindly check.