I am working with a Quectel EC200A-EU module and I am seeing different behavior between two firmware versions when configuring USB networking (RNDIS/ECM).
Firmware version that works correctly
On the non-Quick Python firmware:
AT
OK
AT+QNETDEVCTL=3,1,1
OK
AT+QCFG="usbnet",3
OK
AT+QCFG="nat",1
OK
ATI
Quectel
EC200A
Revision: EC200AEUHAR01A04M16
OK
AT+CFUN=1,1
OK
With this firmware, enabling the network and configuring USB networking works as expected. The NAT configuration also works correctly, and the module does not reboot unexpectedly.
Firmware version with Quick Python
However, on the following firmware:
AT
OK
ATI
Quectel
EC200A
Revision: EC200AEUHAR01A09M16_OCPU_QPY
OK
AT+QGMR
EC200AEUHAR01A09M16_OCPU_QPY
OK
AT+QCFG="usbnet",3
OK
AT+QNETDEVCTL=3,1,1
OK
AT+CFUN=1,1
OK
RDY
AT+QCFG="nat",1
OK
AT+CFUN=1,1
OK
RDY
RDY
RDY
ATI
Quectel
EC200A
Revision: EC200AEUHAR01A09M16_OCPU_QPY
OK
As soon as I enable the network, the module resets/reboots.
The important point is that the same configuration works correctly on:
EC200AEUHAR01A04M16
but causes a reboot on:
EC200AEUHAR01A09M16_OCPU_QPY
I would like to know:
Is there any known issue with QNETDEVCTL or usbnet=3 on the OCPU_QPY firmware?
Is AT+QCFG="nat",1 supported with this firmware and USB networking mode?
Is there a different sequence of commands required for enabling RNDIS/ECM on the OCPU_QPY firmware?
Could this behavior be related to the Quick Python/OCPU firmware itself?
Is there a newer firmware version that fixes this issue?
Any information about the correct configuration sequence or known firmware limitations would be appreciated.
I am currently using the QuecPython API. However, the issue is that the QuecPython API does not provide an option to disable NAT.
As you can see, with the non-QuecPython firmware, we are able to disable NAT successfully.
Is there any way to disable NAT when using QuecPython on this module? If not, is there another API or configuration that would allow us to achieve this?
On my Linux host, I bring up the usb0 interface and run udhcpc to obtain an IP address. The interface receives what appears to be the modem’s public IP address, and basic connectivity tests, including ping, work correctly.
However, when I try to download data over HTTP or HTTPS using curl—for example, when requesting the Google homepage—the modem unexpectedly resets itself.
My suspicion is that this may be a bug or stability issue in the QuecPython firmware, possibly related to USB ECM or network traffic handling.