hey @LateParrot the debug logs is good, but I’m afraid it doesn’t tell much 
Your log shows how when you open the ttyUSB0, there is no data received in the program, and that’s a problem. The way the protocol detection works in qmi-firmware-update is quite simple, it just opens the TTY and waits for the “hello request” sent by the modem, there is no data sent by the program beforehand, it just waits for the modem to speak first (this is done on purpose, if anything is sent to the ttyUSB0 before the hello request, the process will fail later on).
I’m still thinking that your issue could be a problem on the ttyUSB you’re using to run qmi-firmware-update, I have two theories:
- You run qmi-firmware-update very quickly after running qmicli --dms-set-operating-mode=reset, and so you’re not waiting for the module to reboot itself ( it may take 5s-10s for that to happen). The way to make sure this is not the case is to monitor the kernel events e.g. with “dmesg” and make sure the module goes away and then it comes back again. Only when it has come back again, you should run qmi-firmware-update -U.
- The second theory, if the previous one is no the culprit, is that you may have some other device in the system exposing a ttyUSB, and so the port to use may not be ttyUSB0 but ttyUSB1 or some other thing. Again, monitoring dmesg could help here, and once the module has rebooted in single-tty mode, you would check e.g. which is the ttyUSB with the biggest number.
I acknowledge that all this is prone to error, but again this only happens in openwrt because it doesn’t have udev. In a normal system with udev you don’t need to do all these manual steps, just running --update with the files to update and everything is automagically done, even device detection. There may be a way to improve this in openwrt, e.g. by doing some busy wait to look for the device coming back, e.g. checking every 5s for it to be exposed. That is probably a better thing than requiring all the manual steps done by the user, truth be told.