Quectel EC25‑E / EG25‑G Mini PCIe 4G modems supported

[(MARLOO)]

Hi,

I'm running:

OPNsense: 26.7.5‑amd64

FreeBSD: 15.1‑RELEASE‑p3

on a Topton/CWWK‑style N100/N5105 firewall mini‑PC with:

1× Mini PCIe slot for WiFi/3G/4G (USB protocol)

1× onboard SIM slot

I want to add a 4G/LTE Mini PCIe modem as a secondary WAN (failover).

I've been following this issue about Quectel modems breaking after 24.7 and the related GitHub thread:

Forum: "LTE Modem Failure after Upgrade 24.1 to 24.7"
https://forum.opnsense.org/index.php?topic=41751.0

GitHub: "LTE Modem Failure after Upgrade 24.1 to 24.7"
https://github.com/opnsense/src/issues/214

Given that context, are the following modems supported on OPNsense 26.7.5 / FreeBSD 15.1?

Quectel EC25‑E Mini PCIe

Quectel EG25‑G Mini PCIe

If not, which Mini PCIe 4G/LTE modem is currently known to work reliably with this OPNsense version?

Thanks in advance for any info.

[nero355]

Have a look at https://docs.opnsense.org/manual/how-tos/cellular.html#configuring-cellular-modems and see if they are listed there :)

[(MARLOO)]

Hi,

Thanks for the pointer to the docs.

Yes, both modems are supported on OPNsense 26.7.5 / FreeBSD 15.1.

The FreeBSD u3g driver (used by OPNsense for 3G/4G modems in PPP mode) explicitly lists Quectel EC25 (including EC25-E/EC25-A) and related models (EM05, EG91, EG25-G) as supported devices. 


From what I understand, the issue there is a regression in PPP behavior after 24.7, not a lack of hardware support: the EC25 is still listed in the FreeBSD u3g driver, but some users saw dial-up failures or needed extra AT commands/init strings.

Other users with Quectel EC25/EG25-G on OPNsense 24.7+ reported:

PPP dial-up failing after upgrade (worked on 24.1, broken on 24.7/25.x). 

Chat script errors in logs:

CHAT: The modem is not responding to "AT" at MomCmd: labeell.

CHAT: line 358: label "MomIdentGeneriicc" not found (typos in internal script). 

Reconnection loops:

Link: reconnection attempt 148 in 3 seconds

LCP: Down event, MODEM: chat script failed. [github.com]

PPP interface never gets IP/gateway:

ROUTING: refusing to set interface route on addressless opt1(ppp1). [github.com]


Common workarounds:

Add custom init string in PPP device (e.g. &F&C1&D2E0S0=0${temp}). [github.com]

Manually patch /usr/local/opnsense/scripts/interfaces/mpd.script to fix label typos (lost on each update). [github.com]

Some switched to an external 4G/5G router instead of internal modem. [github.com]
------------------------------------------------------------------------------------------------------------------------------------------------------------------

My question is specifically about the current stack:

OPNsense 26.7.5‑amd64

FreeBSD 15.1‑RELEASE‑p3

On this version, has anyone successfully run:

Quectel EC25‑E Mini PCIe

Quectel EG25‑G Mini PCIe

as a secondary WAN (failover) without major issues? Or have the PPP problems persisted into 26.7?

[franco]

As far as I know that's still an issue but nobody talks about it anymore.  Something wrong with FreeBSD since 14 I think, but never found out why.

But didn't https://github.com/opnsense/core/commit/fe4c91516a35c fix this on our end? It was introduced in 25.7.1 more than a year ago.


Cheers,
Franco

[(MARLOO)]

Hi Franco,

Thank you for the clarification and for pointing out the commit
https://github.com/opnsense/core/commit/fe4c91516a35c

From what I understand, this change (introduced in 25.7.1) should have addressed part of the PPP/chat script issue on the OPNsense side, while some underlying problems in the FreeBSD stack since 14 (and now 15.1) may still remain.

For the time being, I will keep this thread open on my end. Once I receive the modem and deploy it on OPNsense 26.7.5 / FreeBSD 15.1, I will perform a structured test as a secondary WAN (failover) and follow up with a detailed report, including:

Modem model (EC25‑EUX ) and firmware version

PPP configuration (init string, APN, dial number)

Whether the connection establishes reliably out of the box or requires additional workarounds beyond the fix in the above commit.

This should provide a concrete data point for the current stack.

Thanks