I have an LtAP LTE6 device, it has 3 SIM slots, I’m using the top one only (slot 1) and would like to set up periodic restart of the SIM card, let’s say once a week.
I’ve learnt here on the forums and the docs that I just need:
Command system/resource/usb/print will show (among others) device identification in format -. Hopefully at least bus number doesn’t change with each reboot …
# DEVICE VENDOR NAME SPEED
0 1-0 Linux 3.3.5 xhci-hcd xHCI Host Controller 480
1 2-0 Linux 3.3.5 xhci-hcd xHCI Host Controller 5000
2 1-1 MikroTik R11e-LTE6 480
Which line corresponds to what here? And the first numbers of each line are the bus numbers?
What I’m confused about is that the last line has LTE6 in the name but there are 3 SIM slots and according to the block diagrams not all of them are on the same bus (at least that’s what I think, could be wrong).
So how would I find the bus number for the top SIM slot?
I don’t have a LtAP LTE6 so I can’t say this with confidence. But the way I understand product description and block diagram, the device has only one LTE modem built in (and it’s shown on the output you showed in previous post), connected to USB bus. This card can use either SIM2 or SIM3 slot. Then it is possible to plug another modem, this one connected to mini-PCIe bus and can use SIM1 slot.
Further: as far as I understand, it is possible to select which SIM slot is connected to USB LTE modem, but only when SIM slot is selected, those pins become active. So if SIM2 slot is selected and LTE modem is reset, this also affects SIM card in SIM2 slot. At the same time SIM3 is completely disconnected and SIM card, plugged in that slot, is shut down as much as it gets.
So when you mentioned “restart SIM card” in your opening post, I’m assuming you actually want to restart LTE modem … which is what you can (hopefully) perform by cutting power to USB bus, carrying LTE modem.
Which brings us to the output you showed in previous post. The first column is simply sequential number (print always shows it and in some contexts it’s usable). The second column is -. The rest is some info about device.
USB is a bus, meaning one bus can have multiple devices connected. There’s always one master device (compurer’s or router’s USB controller) and zero, one, or many slave devices. Your output shows exactly one slave device (Mikrotik R11e-LTE6 connected @480[Mbps]) and it’s “bus #1, device #1”.
Thanks a lot, I tried it, but nothing happens. The device is at a remote location, I log via ssh (using the LTE connection given by the SIM card), issue
/system routerboard usb power-reset
and also
/system routerboard usb power-reset duration=10s bus=1
and the ssh connection is still live, so for sure the LTE modem did not power down.
There is only one modem to reset, so if you pick the wrong one, nothing will happen. So you can just try in winbox to confirm… You’ll notice the LTE interface go away for at least the time specified in /system/routerboard/power-reset & you can be sure you have the right one.
The bus# will persist reboot. I have seen them get reversed on older RB953s, but even then it was consistent through upgrades/etc, but bus0 didn’t always mean the same miniPCIe modem slot across units… So I’d just test it manually first to be sure you have the right number without waiting a week to find out .
As @mkx notes, it’s not the SIM slot but the physically modem card that gets its power dropped for the time specific.
That’s odd, I’ve seen old bugs cause them to not come back AFTER a power-reset… but never not turn off FIRST.
I think the default is 5s, so perhaps add a duration=30s so you have plenty of time to check. Also does the RouterBOOT firmware match the RouterOS version (also in /system/routerboard)?
Well, a 5s power down should cut the ssh connection over LTE for sure I issue the power-reset and the terminal is happily working as if nothing happened.
So I upgraded the firmware to match the RouterOS version, both are 6.49.8, but still absolutely nothing happens with any of the following:
/system routerboard usb power-reset bus=0 duration=10s
/system routerboard usb power-reset bus=1 duration=10s
/system routerboard usb power-reset bus=2 duration=10s
How is this possible? Or what can I do to debug it?
The entire question came about because I’d like to force a periodic reconnect of the SIM card (disconnect from the mobile network and then reconnect) let’s say once every week. Is there another way to achieve this if the power-reset doesn’t work?
Strange. Since your remote… one of those should have dropped your connection.
I haven’t use V6 in a long time with LTE, but never seen the power-rest not work. About all you can do to troubleshoot is make sure the version is latest. I suppose you can check the modem firmware is also current using /interface/lte/firmware-upgrade lte1 – but the modem isn’t really involved in power-reset. But the underlying modem dropped ever 1-2 weeks might be fixed by a modem firmware – so worth it to check.
I’d create a supout.rif include that in a ticket at help.mikrotik.com. One of those commands should have cut power to the modem AFAIK.
When on line with MT support it would be worth to ask if those mini-PCIe slots actually are powered via USB bus. It could be that they are powered independently (if they’re dual-bus, USB and PCIe, then they need independent powering for times when PCIe device uses the slot) and in this case it would be normal that usb power off command does nothing.
And in this case you’ll have to find a way to do full modem reset without cutting the power.
Fair point. The LtAP does have the dual miniPCIe/USB slot and switch on shared USB bus between physical port and miniPCIe slot…
I guess that’s another thing to try. Explicitly set the shared USB bus to “miniPCIe” (and not USB Type-A), if it’s not already, also in /system/routerboard. But I’d imagine it’s already set since the modem wouldn’t come up AFAIK with that setting.
Fantastic, this watchdog feature is exactly what I was looking for and I was not aware of it I thought I’d need to implement something like this from bits and pieces but this is perfect, thanks a lot!
The reset really should work, but not sure what’s going here… But @mkx discusses PCI vs USB, the cause for concern is illistrated by “block diagram” on the product page:
But watchdog is likely want you’d want anyway. Especially, if remote and you only have LTE WAN uplink.
A couple notes here:
it also covers kernel panics too
there are some email options, but since most SMTP servers requires authentication… that needs to be set in /tool/e-mail which the watchdog will reference to send the emails.
if it generates a supout.rif, while these are for Mikrotik support, they do contain the logs and config at time watchdog triggering. But if you create an account at www.mikrotik.com, there is a supout.rif “reader” on the account page – this is helpful since logs could have rolled and to see same data in supout.rif files it generates.
.
