EG25-GL QMMSEND returns +QMMSEND: 769,0 despite active PDP context and reachable MMSC

quecteluser69 · September 1, 2026, 7:14am

EG25-GL `QMMSEND` returns `+QMMSEND: 769,0` despite active PDP context and reachable MMSC

Hello,

I am trying to send MMS messages using a Quectel EG25-GL connected through a Seeed Studio Raspberry Pi 4G LTE HAT.

I am using a Tello Mobile SIM in the United States. I am able to register on the network and establish a working data connection, but AT+QMMSEND immediately returns:

+QMMSEND: 769,0

According to the Quectel documentation, error 769 indicates that the PDP context is deactivated. However, I have verified that the PDP context remains active and that I can reach the MMSC independently.

Modem / firmware

AT+CGMR
EG25GLGAR07A03M1G_A0.300.A0.300

ATI
Quectel
EG25-GL
Revision: EG25GLGAR07A03M1G

Network registration

The Tello SIM can see the expected networks:

AT+COPS=?
+COPS: (1,"Mint","Mint","310260",7),(1,"Verizon","Verizon","311480",7),(3,"FirstNet","FirstNet","313100",7),(1,"AT&T","AT&T","310410",7),(3,"312 190","312 190","312190",7),(3,"T-Mobile","T-Mobile","310830",7),,(0-4),(0-2)

I manually selected PLMN 310260, after which I obtained:

AT+CEREG?
+CEREG: 0,1

AT+CGATT?
+CGATT: 1

At one point QNWINFO showed LTE:

+QNWINFO: "FDD LTE","310260","LTE BAND 12",800

The MMS problem also occurs while the PDP context is demonstrably active.

PDP configuration

Tello uses the following APN configuration:

APN: wholesale
MMSC: http://wholesale.mmsmvno.com/mms/wapenc
MMS proxy: blank
MMS port: 8080

I configured PDP context 1 as:

AT+QICSGP=1,1,"Wholesale","","",0
OK

AT+QIACT=1
OK

The context is active:

AT+QIACT?
+QIACT: 1,1,1,"48.16.30.192"
OK

AT+CGACT?
+CGACT: 1,1
+CGACT: 2,0
+CGACT: 3,0
+CGACT: 4,0
OK

AT+CGPADDR=1
+CGPADDR: 1,"48.16.30.192"
OK

AT+CGATT?
+CGATT: 1
OK

So the PDP context is still active when QMMSEND is attempted.

MMS configuration

I configured:

AT+QMMSCFG="contextid",1
OK

AT+QMMSCFG="mmsc","http://wholesale.mmsmvno.com/mms/wapenc"
OK

AT+QMMSCFG="proxy","",8080
OK

AT+QMMSCFG="character","UTF8"
OK

I also tried the Quectel-recommended representation for a NULL proxy:

AT+QMMSCFG="proxy"," ",80

but this did not resolve the issue.

The current configuration can be queried successfully:

AT+QMMSCFG="contextid"
+QMMSCFG: "contextid",1

AT+QMMSCFG="mmsc"
+QMMSCFG: "mmsc","http://wholesale.mmsmvno.com/mms/wapenc"

MMS composition

I successfully created an MMS recipient and attachment:

AT+QMMSEDIT=0
OK

AT+QMMSEDIT=1,1,"+16809658853"
OK

AT+QMMSEDIT=5,1,"RAM:hello.txt"
OK

The attachment can be queried:

AT+QMMSEDIT=5
+QMMSEDIT: 5,"RAM:hello.txt"

OK

The subject is also present:

AT+QMMSEDIT=4
+QMMSEDIT: 4,"UTF8","54657374204D4D53"

OK

54657374204D4D53 is the UTF-8 representation of Test MMS.

MMSC connectivity test

I also tested connectivity to the MMSC independently of QMMSEND.

DNS resolution works:

AT+QIDNSGIP=1,"wholesale.mmsmvno.com"
OK

+QIURC: "dnsgip",0,1,2
+QIURC: "dnsgip","10.175.205.67"

A TCP connection to port 80 succeeds:

AT+QIOPEN=1,1,"TCP","10.175.205.67",80,0,0
OK

+QIOPEN: 1,0

I also tested port 8080:

AT+QIOPEN=1,0,"TCP","10.175.205.67",8080,0,0
OK

+QIOPEN: 0,566

Finally, using the Quectel HTTP commands, I was able to reach the MMSC over HTTP:

AT+QHTTPURL=42,60
CONNECT

[URL entered]

OK

AT+QHTTPGET=60
OK

+QHTTPGET: 0,400,0

The HTTP 400 response seems reasonable because I was sending an ordinary HTTP GET to an MMS endpoint rather than a valid MMS POST. The important point is that the modem successfully reached the server and received an HTTP response.

MMS send failure

Despite the above, sending the MMS produces:

AT+QMMSEND=60
OK

+QMMSEND: 769,0

The response is essentially immediate.

I have also checked the PDP context immediately after the failure:

AT+QIACT?
+QIACT: 1,1,1,"48.16.30.192"

AT+CGACT?
+CGACT: 1,1
+CGACT: 2,0
+CGACT: 3,0
+CGACT: 4,0

AT+CGATT?
+CGATT: 1

The PDP context is still active.

Questions

Could someone from Quectel help clarify the following?

Why does QMMSEND return 769,0 when PDP context 1 is still active?
Does QMMSEND require a separate PDP context specifically for MMS, even when the carrier uses the same APN for both data and MMS?
Tello’s iOS configuration specifies service as the MMS APN, while its Android configuration uses wholesale with APN Type=default,supl,mms. Should I configure a second PDP context using service and set:
```
AT+QMMSCFG="contextid",2
```
for MMS?
Does firmware EG25GLGAR07A03M1G_A0.300.A0.300 have any known issues with MMS, particularly with carriers that use a proxy-less MMSC?
Is there a newer EG25-GL firmware that I should be using?
Is AT+QMMSCFG="proxy"," ",80 the correct way to configure a NULL MMS proxy on the EG25-GL, or is there another configuration required for direct MMSC access?
Is there a recommended way to enable additional logging/debug information for QMMSEND so that I can determine exactly where the 769 error is generated?

I would appreciate any guidance on the correct QMMSCFG/PDP configuration for Tello, or whether this is a known firmware limitation/bug.

Thank you.

fazrulredzuan · September 2, 2026, 8:42am

Dear Customer,

Thank you for providing the detailed logs. Your results confirm that the module is registered, PS-attached, and that context 1 remains active before and after AT+QMMSEND.

In this situation, +QMMSEND: 769,0 should not be interpreted as confirmation that the network has actually deactivated PDP context 1. The error is generated by the internal MMS application. Since AT+QIACT? continues to show the context active and the HTTP response value is 0, the failure appears to occur before the MMS POST request reaches the MMSC.

Please perform the following isolation test.

First, temporarily stop any Raspberry Pi data connection using PPP, QMI, MBIM, quectel-CM, ModemManager, or NetworkManager. A context used by the host-side data connection should not also be used by the module’s internal MMS stack.

After rebooting the module, configure a dedicated context 2 for MMS:

AT+COPS=0
AT+CGATT?
AT+QIDEACT=2
AT+QICSGP=2,1,"service","","",0
AT+QIACT=2
AT+QIACT?
AT+QICSGP=2

An error from AT+QIDEACT=2 can be ignored if context 2 was already inactive.

If context 2 activates successfully and obtains an IPv4 address, configure MMS as follows:

AT+QMMSCFG="contextid",2
AT+QMMSCFG="mmsc","http://wholesale.mmsmvno.com/mms/wapenc"
AT+QMMSCFG="proxy"," ",80
AT+QMMSCFG="character","UTF8"
AT+QMMSCFG="sendparam",6,2,0,0,2,4

Then query the complete configuration:

AT+QMMSCFG=?
AT+QMMSCFG="contextid"
AT+QMMSCFG="mmsc"
AT+QMMSCFG="proxy"
AT+QMMSCFG="sendparam"

Please re-upload the attachment after rebooting because it is stored in RAM, and confirm that the file exists and has a non-zero size:

AT+QFLST="RAM:*"

Re-create the MMS and retry:

AT+QMMSEDIT=0
AT+QMMSEDIT=1,1,"<destination_number>"
AT+QMMSEDIT=4,1,"54657374204D4D53"
AT+QMMSEDIT=5,1,"RAM:hello.txt"
AT+QMMSEND=120

If the service APN cannot be activated, please repeat the same test using wholesale on context 2:

AT+QIDEACT=2
AT+QICSGP=2,1,"wholesale","","",0
AT+QIACT=2
AT+QMMSCFG="contextid",2

A separate MMS context is not always required when the operator uses the same APN for data and MMS. However, it is recommended here to eliminate any conflict with the LTE default bearer or the Raspberry Pi host data connection.

Regarding the proxy configuration, AT+QMMSCFG="proxy"," ",80 is the previously recommended representation for a NULL proxy. Port 8080 should not be used as the proxy port in this case because your own TCP test shows that the MMSC is reachable on port 80 but not on port 8080. There is currently no other documented command for completely removing the MMS proxy.

If both dedicated-context tests still immediately return +QMMSEND: 769,0, the remaining likely cause is a firmware limitation in the handling of a proxy-less MMSC. Your ordinary HTTP GET confirms IP routing and MMSC reachability, but it does not confirm that the internal MMS client can operate without a proxy.

There is no public verbose mode for AT+QMMSEND. For further analysis, please provide:

ATI
AT+QGMR
AT+QCFG="usbnet"
AT+CGDCONT?
AT+QICSGP=1
AT+QICSGP=2
AT+QIACT?
AT+CGACT?
AT+QMMSCFG=?
AT+QMMSCFG="contextid"
AT+QMMSCFG="mmsc"
AT+QMMSCFG="proxy"
AT+QMMSCFG="sendparam"

Please also provide a timestamped AT log from module startup until the failure. If the error remains after the above isolation test, a diagnostic log captured from the module’s DM/DIAG port will be required to determine exactly why the MMS application reports the context as unavailable.

We will also need to check whether a newer firmware exists specifically for the EG25GLGAR07A03M1G branch. Firmware from another EG25-G or EG25-G-GB branch must not be cross-flashed onto this module.

Regards,

Fazrul

quecteluser69 · September 3, 2026, 5:55am

Hello Quectel Support,

Thank you for your previous guidance. I have now completed the isolation test using QCOM directly connected to the EG25-GL. The Raspberry Pi and all host-side cellular networking software were completely removed from the test.

The important new result is that MMS delivery works successfully when I use the EG25-GL’s generic HTTP commands (QHTTP*) to manually construct and POST an MMS PDU, but the built-in QMMSEND MMS application consistently returns +QMMSEND: 769,0.

This appears to isolate the problem to the EG25-GL’s internal MMS application rather than the cellular connection, APN, MMSC, or MMS message itself.

Module / firmware

ATI

Quectel
EG25-GL
Revision: EG25GLGAR07A03M1G

OK

AT+QGMR

EG25GLGAR07A03M1G_A0.300.A0.300

OK

Network

The modem successfully registers on T-Mobile/Tello. For example:

AT+CEREG?
+CEREG: 0,1

AT+CGATT?
+CGATT: 1

AT+QNWINFO
+QNWINFO: "FDD LTE","310260","LTE BAND 4",2300

Dedicated PDP context test

Following your instructions, I configured context 2 with Tello’s service APN:

AT+QIDEACT=2
AT+QICSGP=2,1,"service","","",0
AT+QIACT=2
AT+QIACT?

+QIACT: 2,1,1,"48.90.29.116"

So context 2 successfully activated and obtained an IPv4 address.

I then configured the MMS application exactly as recommended:

AT+QMMSCFG="contextid",2
AT+QMMSCFG="mmsc","http://wholesale.mmsmvno.com/mms/wapenc"
AT+QMMSCFG="proxy"," ",80
AT+QMMSCFG="character","UTF8"
AT+QMMSCFG="sendparam",6,2,0,0,2,4

The configuration verified as:

AT+QMMSCFG="contextid"
+QMMSCFG: "contextid",2

AT+QMMSCFG="mmsc"
+QMMSCFG: "mmsc","http://wholesale.mmsmvno.com/mms/wapenc"

AT+QMMSCFG="proxy"
+QMMSCFG: "proxy"," ",80

AT+QMMSCFG="sendparam"
+QMMSCFG: "sendparam",6,2,0,0,2,4

The MMS was composed successfully and the attachment was present in RAM.

However:

AT+QMMSEND=120
OK

+QMMSEND: 769,0

I also repeated the test using the wholesale APN on context 2. Context 2 successfully activated with wholesale as well, but QMMSEND again returned:

+QMMSEND: 769,0

No host-side data connection

For this testing, QCOM was connected directly to the EG25-GL. There was no Raspberry Pi cellular connection, PPP, QMI, MBIM, ModemManager, NetworkManager, or quectel-CM involved.

Therefore, the 769,0 result is reproducible without any host-side data connection competing for the PDP context.

MMSC connectivity independently verified

I also tested the MMSC using the EG25-GL’s generic HTTP commands.

DNS resolution succeeds:

AT+QIDNSGIP=1,"wholesale.mmsmvno.com"

+QIURC: "dnsgip",0,1,2
+QIURC: "dnsgip","10.175.205.67"

A TCP connection to the MMSC on port 80 succeeds:

AT+QIOPEN=1,1,"TCP","10.175.205.67",80,0,0
OK

+QIOPEN: 1,0

A generic HTTP GET to the MMSC also receives an HTTP response:

AT+QHTTPGET=60
OK

+QHTTPGET: 0,400,0

The HTTP 400 is expected because this was a normal GET to the MMS endpoint; the important point is that the modem successfully connected to the MMSC and received an HTTP response.

Most importantly: manual MMS HTTP POST works

I then wrote a Python script that uses the EG25-GL’s generic QHTTPPOST commands rather than QMMSEND.

The script:

Activates a PDP context.
Configures QHTTP to use that context.
Constructs an MMS m-send-req PDU.
Sends:

POST /mms/wapenc HTTP/1.1
Host: wholesale.mmsmvno.com
Content-Type: application/vnd.wap.mms-message
Content-Length: ...
Connection: close

followed by the binary MMS PDU.

This successfully sends an MMS and the recipient receives it.

Therefore, the following have now been demonstrated to work:

Tello SIM/network registration
T-Mobile LTE packet attachment
wholesale APN
service APN
PDP context activation
IPv4 connectivity
DNS resolution
TCP connectivity to the MMSC
HTTP communication with the MMSC
MMS HTTP POST
MMS m-send-req PDU
Actual MMS delivery

The only failing component is the EG25-GL’s QMMSEND MMS application.

Potentially relevant discrepancies

I noticed two unusual results in the diagnostic information:

AT+QIACT?

+QIACT: 2,1,1,"48.90.28.173"

but:

AT+CGACT?

+CGACT: 1,1
+CGACT: 2,0
+CGACT: 3,0
+CGACT: 4,0

Thus QIACT reports context 2 as active, while CGACT reports context 2 as inactive.

Also:

AT+QICSGP=2

+QICSGP: 1,"wholesale","","",0

rather than returning context ID 2.

Could you please confirm whether these results are expected behavior on the EG25-GL, particularly on firmware:

EG25GLGAR07A03M1G_A0.300.A0.300

or whether they indicate a problem with PDP context handling?

Question

Given that a manually constructed MMS HTTP POST works through QHTTPPOST, but the internal MMS application consistently returns +QMMSEND: 769,0, could you please advise:

Why would QMMSEND consider the PDP context unavailable when QIACT? shows it as active and the same modem can successfully use the connection for HTTP?
Is there an additional requirement for the PDP context when it is used by QMMSEND that is not required by QHTTPPOST?
Are the QIACT/CGACT and QICSGP discrepancies described above expected?
Is there a known firmware issue with QMMSEND and proxy-less MMSC configurations?
Is there a newer firmware specifically for the EG25GLGAR07A03M1G branch that addresses this issue?
If not, can you provide instructions for capturing the required DM/DIAG log so that the internal MMS application’s failure can be investigated?

Thank you for your help. The fact that the same module can successfully deliver MMS using QHTTPPOST should hopefully make it possible to isolate the issue specifically to the QMMSEND implementation.

fazrulredzuan · September 4, 2026, 2:31am

Dear Customer,

Thank you for completing the detailed isolation test and for confirming successful MMS delivery through AT+QHTTPPOST.

Based on your latest results, we agree that the cellular network, APN, PDP activation, DNS resolution, MMSC connectivity, and MMS PDU itself have been sufficiently verified. Since the same EG25-GL can successfully deliver the MMS through the generic HTTP stack, there is no need to repeat the previous APN or host-side isolation tests.

Regarding the command results you highlighted:

AT+QICSGP=2

The following response is expected:

+QICSGP: 1,"wholesale","","",0

The first value in this response is the context protocol type, not the context ID:

1 = IPv4
2 = IPv6
3 = IPv4v6

Therefore, this output confirms that context 2 is configured as IPv4 with the wholesale APN. It does not indicate that the command returned context 1.

AT+QIACT? compared with AT+CGACT?

These commands query different data-call interfaces.

AT+QIACT? reports contexts activated for the module’s internal Quectel TCP/IP stack, which is used by commands such as QHTTP, QIOPEN, and QMMSEND.

AT+CGACT? reports the activation state of 3GPP PDP contexts associated with AT+CGDCONT. Its context numbering should not be assumed to directly represent the internal QIACT context state.

Therefore:

+QIACT: 2,1,1,"48.90.28.173"

together with:

+CGACT: 2,0

does not, by itself, mean that QIACT context 2 is invalid. Your successful QHTTPPOST using context 2 provides direct confirmation that the internal context is active and capable of transferring data.

QMMSEND result

There is no additional documented PDP activation step for QMMSEND beyond:

AT+QICSGP
AT+QIACT
AT+QMMSCFG="contextid",<contextID>

You have already completed these steps correctly with both the service and wholesale APNs.

The following result:

+QMMSEND: 769,0

is therefore not consistent with the actual availability of the internal PDP context. The HTTP response value is also 0, indicating that the QMMSEND application failed before receiving any HTTP response from the MMSC.

Because a manually generated MMS PDU can be delivered successfully through QHTTPPOST, the current evidence points specifically to the built-in QMMSEND implementation. The most likely area is its handling of a NULL or proxy-less MMS configuration on this firmware.

We also noted that the current MMS Application Note lists EG25-G but does not list EG25-GL among its applicable modules. Therefore, we need to verify the exact support status and proxy-less MMSC compatibility of QMMSEND on the EG25GLGAR07A03M1G firmware branch. The presence of the MMS AT commands alone does not confirm that all MMS configurations are supported on this product branch.

For the time being, your working QHTTPPOST implementation can be used as a valid workaround, provided that your application also handles the MMSC HTTP response and MMS response PDU correctly.

To proceed with firmware-level investigation, please provide the following:

Complete timestamped AT log for the failed QMMSEND test.
Complete timestamped AT log for the successful QHTTPPOST test.
A sanitized copy of the Python script and MMS PDU, with the telephone numbers and other private information removed.
The output of:

ATI
AT+QGMR
AT+QMMSCFG=?
AT+QMMSCFG="contextid"
AT+QMMSCFG="mmsc"
AT+QMMSCFG="proxy"
AT+QMMSCFG="sendparam"
AT+QICSGP=2
AT+QIACT?
AT+CGDCONT?
AT+CGACT?

For the DM/DIAG capture, please use the Quectel USB DM Port rather than the AT port:

Confirm that “Quectel USB DM Port” is visible in Windows Device Manager.
Close any other program that may be accessing the DM port.
Open the Quectel diagnostic logging tool and select the corresponding DM COM port.
Start the capture before activating the PDP context.
Reproduce the failure once with AT+QMMSEND.
Wait approximately 10 seconds after receiving +QMMSEND: 769,0.
Stop the capture and save the complete, unmodified output folder.
Record the exact PC timestamp when AT+QMMSEND was executed.

The appropriate diagnostic tool and log configuration must match the EG25-GL platform and can be provided privately if required.

We will also check whether a newer firmware is available specifically for the EG25GLGAR07A03M1G branch. Firmware belonging to EG25-G, EG25-G-GB, or another firmware branch must not be used on this module.

Thank you again for the thorough testing. Your successful manual MMS POST is particularly useful because it narrows the remaining investigation to the internal QMMSEND implementation.

Regards,
Fazrul