LT500 cannot initialize SIM card

[OlivierMa]

Hello,
I'm having a very serious problem with my Cudy LT500 router (V2 hardware). When my SIM card was inside the router, it would reboot almost every minute. I managed to have access to the log by removing the SIM card, and I could see that there were "kernel oops" several times, which probably explains the reboots. The SIM card belongs to Lebara (France), I don't know if it's already been reported.
As a consequence, I've tried several things to improve the situation, but it went from bad to worse, and I need some help now. After reading some messages in the forum, I've tried to put the modem in MBIM mode with the AT command AT+QCFG="usbnet",2 in the latest firmware interface. It gave a "OK". I tried AT+QCFG="usbnet",0 but that gave an error. After rebooting, the router can no longer initialize the SIM card: the status stays forever at "initializing". Everything else works, but obviously that's a serious problem that makes the router useless for me.
Reflashing the firmware doesn't change the situation.
As the SIM card doesn't initialize, I no longer have access to the AT command terminal in the luci menu. I've tried to use http://192.168.10.1/cgi-bin/luci/admin/network/gcom/atcmd however I cannot tell if it's working or not: I see a box where I can input characters that are replaced by dots (like a password box) and a box where I can input a command (I guess). I don't know what to put in the first box, and when I put a command in the second box and press the button "AT command", nothing appears in the big box below, where I would expect to see the result of the command.

As you can see, I'm quite stuck at that point, and the first thing is to be able to get back to initializing the SIM card. Can anyone help me?

Thanks and best regards.

[Didneywhorl]

You'll need to contact support@cudy.com for that password for the AT command, unless someone here as it.

I think newer firmware stopped locking the stuff out without sim card initilizing. Do you have the latest firmware? I know you said you reflashed it, but was it with the latest? Just making sure.

[OlivierMa]

You'll need to contact support@cudy.com for that password for the AT command, unless someone here as it.

I think newer firmware stopped locking the stuff out without sim card initilizing. Do you have the latest firmware? I know you said you reflashed it, but was it with the latest? Just making sure.

Hi,
Thanks for trying to help me.
The firmware is indeed the latest one from Cudy: it is 1.15.28 released 2023-04-13. I cannot find older firmwares for hardware V2, to try out if there's also a password. Any clue?

Thanks again.

[Didneywhorl]

Cudy support will be your best bet there.

[OlivierMa]

Cudy support will be your best bet there.

OK, I'm going to contact them. Just to be sure: do you know if sending AT commands to the modem is allowed under Cudy policies? Or is it a process out of warranty and support? Should I mention it or not?

To be honest, I wasn't imagining that the modem configuration could be stored in non volatile Ram, and that there would be no way to reset it with a firmware update. That's a bit crazy to me. If I don't get the password from cudy, is there another way to reset the modem? Maybe by opening the router?

[Didneywhorl]

Shouldn't be a problem. They put tge at command terminal in there for customer use.

There isn't another way to access it that Ive found.

[OlivierMa]

Shouldn't be a problem. They put tge at command terminal in there for customer use.

There isn't another way to access it that Ive found.

Hello,
Here is the final answer from cudy support: they don't provide the AT password, and using the MBIM command bricked the router with no way to unbrick it, according to them! They consider that the AT command is not covered by their support.

That's totally crazy to me. I wonder how people managed to use the MBIM command for Visible without problem. And not giving the password for AT command is also quite a problem...

[Didneywhorl]

Huh. Flash a much older version then. It's not locked. Unless V1 firmware really doesn't work on V2.

[OlivierMa]

Huh. Flash a much older version then. It's not locked. Unless V1 firmware really doesn't work on V2.

Thank you so much for your help. I'm back on an old V2 firmware, and there are no password on the page http://192.168.10.1/cgi-bin/luci/admin/network/gcom/atcmd . However, when I input a command like simply "AT", I don't see any answer in the big box below

at_command.jpg

Maybe it's normal, I don't know. What would be your recommandation now? Try again AT+QCFG="usbnet",0 ? Or do something else? With a SIM card inside or not?

Thank you again.

[Didneywhorl]

Send AT+QCFG="USBNET",0

make sure to click the button, it doesn't take the command from just hitting enter/return

Try with and without SIM.

[OlivierMa]

Send AT+QCFG="USBNET",0

make sure to click the button, it doesn't take the command from just hitting enter/return

Try with and without SIM.

Unfortunately I don't see any difference, and I think that no AT command is sent, because the modem is not available. Here is what I can see in the log:

(...)
Mon Sep 4 19:29:29 2023 daemon.info gcom: reset complete
Mon Sep 4 19:29:29 2023 daemon.info gcom: detect 4g
Mon Sep 4 19:29:29 2023 daemon.info gcom: run script detect 4g
Mon Sep 4 19:29:30 2023 kern.info kernel: [ 3044.597852] usb 1-1: new high-speed USB device number 107 using ehci-platform
Mon Sep 4 19:29:30 2023 kern.info kernel: [ 3045.204466] usb 1-1: USB disconnect, device number 107
Mon Sep 4 19:29:38 2023 kern.info kernel: [ 3052.697816] usb 1-1: new high-speed USB device number 108 using ehci-platform
Mon Sep 4 19:29:45 2023 user.notice 4gup: check lan up 1
Mon Sep 4 19:29:45 2023 daemon.info gcom: detect complete
Mon Sep 4 19:29:45 2023 daemon.info gcom: up 4g
Mon Sep 4 19:29:45 2023 daemon.info gcom: run script 4gup 4g
Mon Sep 4 19:29:46 2023 user.notice 4gup: vendor quectel
Mon Sep 4 19:29:46 2023 user.notice 4gup: no device /dev/ttyUSB1
Mon Sep 4 19:29:46 2023 daemon.info gcom: ubus call 4g reset
Mon Sep 4 19:29:46 2023 daemon.warn gcom: scripts for 4gup running
Mon Sep 4 19:29:46 2023 daemon.info gcom: 4gup retry
Mon Sep 4 19:29:46 2023 daemon.info gcom: up 4g
Mon Sep 4 19:29:46 2023 daemon.warn gcom: scripts for 4gup killed
Mon Sep 4 19:29:46 2023 daemon.info gcom: reset 4g
Mon Sep 4 19:29:46 2023 daemon.info gcom: run script reset 4g
Mon Sep 4 19:29:46 2023 user.notice 4gup: 4greset reset 4g
Mon Sep 4 19:29:46 2023 kern.info kernel: [ 3060.619855] usb 1-1: USB disconnect, device number 108
Mon Sep 4 19:29:46 2023 user.notice 4gup: 4greset exit
Mon Sep 4 19:29:46 2023 daemon.info gcom: reset complete
Mon Sep 4 19:29:46 2023 daemon.info gcom: detect 4g
Mon Sep 4 19:29:46 2023 daemon.info gcom: run script detect 4g
Mon Sep 4 19:29:47 2023 kern.info kernel: [ 3061.377874] usb 1-1: new high-speed USB device number 109 using ehci-platform
Mon Sep 4 19:29:47 2023 kern.info kernel: [ 3061.983330] usb 1-1: USB disconnect, device number 109
Mon Sep 4 19:29:55 2023 kern.info kernel: [ 3069.477810] usb 1-1: new high-speed USB device number 110 using ehci-platform
Mon Sep 4 19:30:02 2023 user.notice 4gup: check lan up 1
Mon Sep 4 19:30:02 2023 daemon.info gcom: detect complete
Mon Sep 4 19:30:02 2023 daemon.info gcom: up 4g
Mon Sep 4 19:30:02 2023 daemon.info gcom: run script 4gup 4g
Mon Sep 4 19:30:02 2023 user.notice 4gup: vendor quectel
Mon Sep 4 19:30:02 2023 user.notice 4gup: no device /dev/ttyUSB1
Mon Sep 4 19:30:02 2023 daemon.info gcom: ubus call 4g reset
Mon Sep 4 19:30:02 2023 daemon.warn gcom: scripts for 4gup running
Mon Sep 4 19:30:02 2023 daemon.info gcom: 4gup retry
Mon Sep 4 19:30:02 2023 daemon.info gcom: up 4g
Mon Sep 4 19:30:02 2023 daemon.warn gcom: scripts for 4gup killed
Mon Sep 4 19:30:02 2023 daemon.info gcom: reset 4g
Mon Sep 4 19:30:02 2023 daemon.info gcom: run script reset 4g
Mon Sep 4 19:30:03 2023 user.notice 4gup: 4greset reset 4g
Mon Sep 4 19:30:03 2023 kern.info kernel: [ 3077.393493] usb 1-1: USB disconnect, device number 110
Mon Sep 4 19:30:03 2023 user.notice 4gup: 4greset exit
Mon Sep 4 19:30:03 2023 daemon.info gcom: reset complete
(...)

The way I interpret this is that /dev/ttyUSB1 should be available for an AT command to be sent, but it never appears. And it goes on and on like that.
Do you have the same understanding of the situation? And any other think to try?
Thank you.