EC200A-AU Issues with OpnSense

IoT Modules LTE Standard Module
1

EC200A-AU Firmware Revision: EC200AAUHAR01A17M16
OpnSense 26.1.10-amd64

I am having problems with my EC200A-AU, which is installed as a Mini PCI-E device in my OpnSense firewall.

The NIC does not appear as a network device in OpnSense and I get the following log entries repeating forever on boot:

2026-07-04T13:35:45	Notice	kernel	 \[158\] ugen0.2:  at usbus0
2026-07-04T13:35:45	Notice	kernel	 \[158\] cdce0 on uhub0
2026-07-04T13:35:45	Notice	kernel	 \[158\] cdce0: <Android Android, class 239/2, rev 2.00/3.18, addr 21> on usbus0
2026-07-04T13:35:46	Notice	kernel	 \[158\] cdce0: No valid alternate setting found
2026-07-04T13:35:46	Notice	kernel	 \[158\] device_attach: cdce0 attach returned 6
2026-07-04T13:35:46	Notice	kernel	 \[158\] ugen0.2:  at usbus0 (disconnected)
2026-07-04T13:35:50	Notice	kernel	 \[163\] ugen0.2:  at usbus0
2026-07-04T13:35:51	Notice	kernel	 \[163\] ugen0.2:  at usbus0 (disconnected)
2026-07-04T13:35:59	Notice	kernel	 \[171\] ugen0.2:  at usbus0
2026-07-04T13:35:59	Notice	kernel	 \[171\] cdce0 on uhub0
2026-07-04T13:35:59	Notice	kernel	 \[171\] cdce0: <Android Android, class 239/2, rev 2.00/3.18, addr 23> on usbus0
2026-07-04T13:35:59	Notice	kernel	 \[172\] cdce0: No valid alternate setting found
2026-07-04T13:35:59	Notice	kernel	 \[172\] device_attach: cdce0 attach returned 6
2026-07-04T13:35:59	Notice	kernel	 \[172\] ugen0.2:  at usbus0 (disconnected)
2026-07-04T13:36:03	Notice	kernel	 \[176\] ugen0.2:  at usbus0
2026-07-04T13:36:04	Notice	kernel	 \[176\] ugen0.2:  at usbus0 (disconnected)

I need some assistance to resolve this issue please.

2

Could I please get a response on my issue @eddy ?

3

Quectel team will respond to you shortly.

1 Like
4

Dear Customer,

Thanks for the detailed log, it helps narrow this down. Two things are going on here.

The cdce0: No valid alternate setting found error is a compatibility issue between the module’s default ECM USB network mode and FreeBSD’s cdce driver, which expects a data-interface alternate setting that the ECM gadget doesn’t present. This is why the interface never comes up in OpnSense. The recommended fix is to switch the module to RNDIS mode, which FreeBSD handles via a different driver (urndis):

  1. Connect to the module’s AT command port (a USB serial terminal on a Windows/Linux PC is easiest for this step).
  2. Query the current mode: AT+QCFG="usbnet"
  3. Set RNDIS: AT+QCFG="usbnet",3
  4. Power-cycle the module and re-check for a ue0 interface.

Separately, the repeating disconnect/reconnect in your log suggests the module may be resetting during enumeration, which is often power-related in an mPCIe slot (LTE transmit current peaks). To confirm, could you test the module briefly on a PC via a powered mPCIe-to-USB adapter and let me know whether it enumerates stably there? That will tell us whether we’re chasing a driver issue, a power issue, or both.

Could you also confirm the module is your only cellular device in that slot, and share the output of usbconfig when it’s connected?

Best regards,
Fazrul Redzuan

1 Like
5

Hi @fazrulredzuan,

Thank you for your comprehensive reply.
I will test with RNDIS mode.

Regarding the potential power related issues; I have connected this module to a PC via a USB to mPCIe adapter and I was able to see it as a device in Windows Device Manager, connect to it via its COM port and run AT commands on it, without issue.

Is this a sufficient test to confirm stability? If not, please direct me as to the test I should perform.

Sam.

6

Dear Customer,

Thanks for running that test, it’s a helpful result. Being able to enumerate the module and issue AT commands over the COM port on a PC confirms the module itself is healthy and rules out a defective unit, so we can set that aside.

One thing to keep in mind, though is that test exercised the module in an essentially idle state. The instability we’re trying to rule out is most likely linked to LTE transmit current peaks, which are significantly higher than the near-zero draw at an idle AT prompt. Since the module wasn’t registered on the network or passing data, the power rail was never actually loaded, so this doesn’t yet confirm stability under real operating conditions, and a PC USB port (or an adapter with its own regulation) is also a different supply from the mPCIe 3.3V rail on your OpnSense board.

That said, the good news is that the RNDIS test you’re already planning is the most efficient next step, because it will help separate the two possible causes. FreeBSD’s failed ECM (cdce) attach can itself trigger a USB port reset, which would produce exactly the disconnect/re-enumeration loop you saw, so that loop may have been a driver mismatch rather than a power problem. The plan:

  1. On the PC, set the module to RNDIS: AT+QCFG=“usbnet”,3
  2. Power-cycle the module, then reinstall it into the OpnSense box.
  3. Check whether a ue0 interface appears (RNDIS is handled by FreeBSD’s in-kernel urndis driver, so no additional driver is needed on OpnSense).

If it comes up as ue0 and the disconnect loop is gone, the loop was the ECM driver mismatch and power was never the issue.

If the loop persists in the firewall even though the module is stable on the PC, then power/slot becomes the likely cause. In that case, please run a loaded test rather than an idle one: insert the SIM and connect the antenna, let the module register (AT+CEREG?), bring up the data call (AT+QNETDEVCTL=1,1,1), then push sustained traffic such as a continuous download or ping and watch for drops during the active transfer. If you have the equipment, monitoring the module’s 3.3V rail for voltage sag during transmit is the definitive check.

Please give the RNDIS step a try and let me know how it enumerates in OpnSense.

1 Like
7

Thanks for that info @fazrulredzuan , setting the USBNet mode to 3 has resolved the looping issue and the interface now shows as “ue0” in the OpnSense UI!

Thank you very much for your assistance with this issue!