EG18-NA firmware

Technical Subjects
1

Hello,
Can you please email me the latest firmware for EG18-NA?
My current firmware is EG18-NA-PAR01A06M4G
Thanks

2

I have sent it to your email,pls check

3

Hello Herbert,

Could you kindly email me the latest firmware for EG18-NA as well?
Thank you.

4

[quote=“Tom074, post:3, topic:32773”]
Hello Herbert,

Could you kindly email me the latest firmware for EG18-NA as well?
Thank you.

1 Like
5

I have sent it to your email,pls check

6

I have sent it to your email,pls check

7

Thank you kindly Mr. Herberts. I received it.

1 Like
8

Do you have a 2025 firmware? I am reading the 2025_01_07 Quectel AT Commands document, and it refers to a AT+QMTUINFO command, which does not work on EG18NAPAR01A06M4G v01.008.01.008 (2024-05-09).

Thanks!

9

@MTTS

Hi， what is your current firmware version? much appreciation.

10

A06 01.008.01.008 Your staff provided it, through this forum. Someone else I was communicating with, was more familiar with cross-compiling than I was, and cross-compiled the Qfirehose app for the IPQ40x platform (LBR20 in this case): it was then possible to flash.

The MTU query is curious, because, as I have reported here, and on the GLiNet forum, and with Openwrt developers on their forum, it does not matter what version of the quectel firmware I use, or whether it’s the same modem chipset type (EC25-AF vs EG18-NA) - if it’s quectel and on either the Netgear or GLiNet platform, running Openwrt, of any recent revision 21-24 (and one would assume, older ones too), if I deviate from using the QMI protocol, and/or set the MTU, or use MBIM which sets the MTU automatically, within 2 minutes of cell connection uptime, reproducibly, the Quectel device hard-locks. I am not able to ‘picocom /dev/ttyUSB2’, etc anymore. I must power-cycle or reboot the entire router. I don’t have the GLiNET GL-X750 EC25-AF combination up and running anymore, but I encountered the same issue as I remember.

This is why, if you are integrating some kind of MTU query, it makes me think perhaps developers finally attempted to address what is some kind of issue, where when the MTU is set (e.g. 1428 instead of default 1500), the quectel modem locks-up. I can’t imagine any scenario where a long-term bug in the open-source OpenWrt software, could feed MTU information to the Quectel, have it work successfully, then in 2 minutes, the quectel device hard-locks. Although Openwrt is a common denominator, I can’t see how architecturally it could be to blame. But quectel’s history of instability of firmwares and hardware issues, could be.