I’m using Quectel EG810M-EU module with Linux Ubuntu 24.04 and I made experimental USB driver for it. I have that module on my custom made PCB. Now I see three serial ports and one Ethernet port visible. I can succesfully communicate with AT commands thru /dev/ttyUSB1 and /dev/ttyUSB2 but serial port /dev/ttyUSB0 is not answering anything because it is for diagnose/upgrade and I don’t know the commands. Apparently it needs QFlash (Windows) or QFirehose (Linux) application but using QFirehose is not possible because I could not find suitable firmware file for it to upload.
Firmware what is downloadable from Quectel site contains *.bin files which are precompiled when QFirehose expects *.mbn file format.
QFlash does not work on Linux with Wine. That was tested by others on the forum. Result of dmesg usb part after my device driver initialization and connecting EG810M-EU:
[104879.608117] usb 1-3: GSM modem (1-port) converter now attached to ttyUSB0
[104879.608945] usb 1-3: GSM modem (1-port) converter now attached to ttyUSB1
[104879.609794] usb 1-3: GSM modem (1-port) converter now attached to ttyUSB2
[104879.702679] cdc_ether 1-3:1.0 usb0: register ‘cdc_ether’ at usb-0000:05:00.3-3, CDC Ethernet Device, ae:0c:29:a3:9b:6d
[104879.702768] usbcore: registered new interface driver cdc_ether
[104879.731178] cdc_ether 1-3:1.0 enxae0c29a39b6d: renamed from usb0
My intention is to program device with QuecPython, but there’s no REPL port. And where is module file system available? If I need to upload new firmware containing QuecPython interface, how to do that via USB?
[104879.353938] usb 1-3: new high-speed USB device number 54 using xhci_hcd
[104879.484000] usb 1-3: New USB device found, idVendor=2c7c, idProduct=6002, bcdDevice= 3.18
[104879.484015] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[104879.484019] usb 1-3: Product: Android
[104879.484022] usb 1-3: Manufacturer: Android
[104879.484026] usb 1-3: SerialNumber: 0000
Apparently there is Android operating system inside a module but ADB is not working because there is no any open ports on it’s IP address. I performed a port scan for all ports.
If I connect USB_BOOT pin to ground via 4k7 ohm resistor before plugging power supply to device and module I got following lines to dmesg:
[148898.372435] usb 1-3: new high-speed USB device number 83 using xhci_hcd
[148898.517053] usb 1-3: New USB device found, idVendor=2ecc, idProduct=3004, bcdDevice= 0.00
[148898.517073] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[148898.517081] usb 1-3: Product: Arom Usb Boot Port
[148898.517089] usb 1-3: Manufacturer: ASR Microelectronics
[148898.517096] usb 1-3: SerialNumber: arom0123456789
But I honestly don’t know how to use that information to anything. Could you help or lead me to right direction how to get QuecPython interface working. Thanks.
Quectel “quality”. I got their Linux Ubuntu 18.04 version of QPYcom V3.0.2 working barely in my Ubuntu 24.04 with VirtualBox where I’m running that older Ubuntu. QPYcom crashes immediately if I unplug EG810M-EU from USB port. It connects but I can’t do anything. There is text “Device not connected”. I can connect to diagnose port tho and sometimes it prints crap to REPL window.
Again at first I compiled my own Linux driver for that module. It uses normal serial ports.
Thanks for trusting my skills to hack your device Quectel. Reverse engineering continues because Quectel gives no information to me for a product I bought from them! Total silence?! I’m a former embedded software developer and I have strong drive to learn more when needed. Internet is endless source of knowledge. Here I wrote my latest results about EG810MEU_LA module.
Helios SDK
It took almost a week to fix all compile errors and other errors in makefiles and sources before I got official Quectel Helios SDK to work on Linux Ubuntu LTS 24.04. There were a lot of bugs. From simple typos to logic problems and missing code parts. And of course product EG810MEU_LA was missing completely from it too. I added it. I compiled new firmware to that module with it, but I have not yet found a solution to how to transfer it to module.
Again if I connect USB_BOOT pin to ground via 4k7 ohm resistor before plugging power supply to device and module I got following lines to dmesg. I think it goes to firmware upload mode.
[379827.843932] usb 1-3: new high-speed USB device number 2 using xhci_hcd
[379827.985423] usb 1-3: New USB device found, idVendor=2ecc, idProduct=3004, bcdDevice= 0.00
[379827.985440] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[379827.985448] usb 1-3: Product: Arom Usb Boot Port
[379827.985456] usb 1-3: Manufacturer: ASR Microelectronics
[379827.985462] usb 1-3: SerialNumber: arom0123456789
[379681.394043] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[379828.036219] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
I think it is recognized and set up right with standard driver. Verbose command of lsusb gives more information of interfaces. There is CDC ACM Gadget Config configuration which contains two interfaces. First (0) is CDC ACM Control Interface and second (1) is CDC ACM Data Interface.
I think it uses Sahara/Firehose protocol because Quectel has published a tool which has the same name (QFirehose). That tool is altough totally useless because Quectel has not published any *.MBN firmware files.
Module with that /dev/ttyACM0 port is recognized and connected with EDL software made by bkerler but module doesn’t respond to any commands. EDL software uses Sahara/Firehose protocol. So that is currently a dead end until I invent something new.
Back to beginning
When device is on normal mode (resistor disconnected) Ubuntu uses a custom USB serial device driver I made from Option device driver which Quectel has modified for the use of some of their modules but not EG810MEU_LA.
[384254.080941] usb 1-3: new high-speed USB device number 3 using xhci_hcd
[384254.209473] usb 1-3: New USB device found, idVendor=2c7c, idProduct=6002, bcdDevice= 3.18
[384254.209491] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[384254.209499] usb 1-3: Product: Android
[384254.209506] usb 1-3: Manufacturer: Android
[384254.209512] usb 1-3: SerialNumber: 0000
[384254.337260] cdc_ether 1-3:1.0 usb0: register 'cdc_ether' at usb-0000:05:00.3-3, CDC Ethernet Device, ae:0c:29:a3:9b:6d
[384254.339187] usb 1-3: Quectel EG810M converter now attached to ttyUSB0
[384254.367369] usb 1-3: Quectel EG810M converter now attached to ttyUSB1
[384254.399548] usb 1-3: Quectel EG810M converter now attached to ttyUSB2
[384254.460323] cdc_ether 1-3:1.0 enxae0c29a39b6d: renamed from usb0
USB network adapter
So it represents one CDC Ethernet Device. Normal TCP scan with Nmap gives zero open port like I told my first post. That is because Android by default blocks all ping calls. But then I discovered UDP scan and it gives many open ports! I also installed wsdd-server so that module recognizes my computer better. That idea came from Ubuntu network log files which told that module is trying to make something about wsdd but did not found it. Unfortunately later I discovered that WSD Client works only in Windows.
3702/udp open|filtered WSD ← Works only from Android to Windows
5353/udp open|filtered zeroconf, mDNS ← Should work in Linux too with Avahi
NNNNN/udp open|filtered unknown
… about ten random port numbers more
It seems that all port candidates but first two ports changes every time when module is restarted. When I try to connect to any candidate with ADB (Android Debug Bridge) it is refused but module creates more additional open ports randomly. I made a Python script that connect automatically for them when they appear, but without success. I noticed that very often that new port number is odd.
There is also always one random open TCP port. I made a python script which scans all ports and connects to that one open TCP port. I noticed that port number is always even number and it is only an echo server. Maybe some kind of false decoy for people like me…
QDownloadProj toolkit
I found again one of the Quectel programming projects from the internet. This time it is QDownloadProj toolkit which claims to be the right download (BTW right term is upload) tool for some of the Quectel products. All documentation is always only in Chinese but luckily AI translation to English is so advanced that it works great so no problem with that. China is not whole World. You should think a little bit of other countries too. English is the universal language.
Big surprise was that after running following compile command DownloadCLI application started smoothly with no problems. I didn’t except that at all.
It’s real name is BTool and it is originally made by EigenCOMM. Seems that it accepts firmware files in right file format as *.BIN. I can make those with Helios APK and download from Quectel Download Zone. But later I discovered that EigenCOMM platform differs from ASR platform what this module is. I tried to download (not upload aka burn) partial memory content to my computer but handshake didn’t success.
QPYcom
Next I accidentally found a mention that QPYcom chooses right tool automatically for burning. QPYcom does not work and I didn’t found it source code for fixing it. But there is folder containing it’s tools and they are not made by Quectel so this idea should work. Apparently there is QFirehose program but later version than I previously used. And now I know that it needs a loader file which is firehose.mbn. Quectel of course has not provided that file for me.
Answer from Stackoverflow site: “Most modern Qualcomm Firehose loaders are actually ELF files (either 32 or 64 bit). They usually have an .elf or .bin extension. If your EDL client is so picky you can just rename the loader.”
But later I discovered that this module uses ASR Microelectronics chip ASR1603 and that is not Qualcomm related in any way.
Thonny + QuecPython plugin
This actually works in Linux. As soon as I get module reflashed I will use this instead of QPYcom for software development. There is also flashing utility in their plugin but, guess what, it does not work. Reason is that all applications what it uses behind the scenes is again Windowshit applications and only them. Please, Quectel engineers, please, think. Half of the World runs Linux.
I modified some of the plugin code so that it runs Windows burning application with Wine on Linux, but didn’t success. Then I searched again from the internet and found luckily a public domain archive package of ASR burning tools and that package included a pre-build version for Linux. I tested it and it hangs on this message:
Next morning with this command I finally got firmware uploaded to module. This took only about a month without Quectel’s help. Now I can make new firmwares with Helios SDK and enable ADB and other things from module.
./adownload -u -a -s 115200 ../../newFW/QPY_OCPU_V0001_EG810M_EULA_FW.zip
I modified again my own driver for EG810MEU_LA because after flash it created new interface number 32 which seems to be QuecPython REPL port! YES! Now it works with Thonny. Thanks for nothing Quectel…
Quecpython v1.12 on Fri_Dec_6_2024_11:27:54_AM ; EG810M with QUECTEL
Reason is that all applications what it uses behind the scenes is again Windowshit applications and only them. Please, Quectel engineers, please, think. Half of the World runs Linux.