FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
+2 votes
1,357 views 6 comments
by anonymous
Hello I am very new to this forum as well as to teltonika router. We have a teltonika router RUT955. It works fine. but sometimes, it dies and we need to do a restart using SMS utilities.

I have a few questions.

1. What could be the possible reason for the RUT955 to be frozen or died.?

2. How can you know or by which UCI command you can still run in any worst-case scenario? Suppose Router has died and you cannot log in to WEBUI. and of course, you need a restart. but SMS still works, How can you get to know which part of the router has stopped working? Can this be done by UCI commands?

3. Can anything be helpful in this situation when a router stops working all of a sudden then we don't do a FULL reboot but only fix that part through any UCI command?

Thank you for your patience, But I am really interested in knowing all those things. as UCI command looks helpful but so complicated that I cant get through what I need right now.

Update: I am on the latest firmware. When I say frozen. It means WEBUI stops, as well as router connection to the NVR, also stops.
by anonymous

Just and Update:

A frozen router gives such response to uci show network..

----------------------------------------------------------

Incoming  Received  proto=none network.wan2.proto=dhcp network.wan2.ifname=eth1 network.wan2.enabled=0 network.wan2.metric=10 network.wan2.disabled=1 network.wan3.proto=dhcp

Incoming  Received  0 network.lan.type=bridge network.lan.proto=static network.lan.ipaddr=192.168.1.1 network.lan.netmask=255.255.255.0 network.wan.ifname=wwan0 network.wan.

Incoming  Received  network.loopback.ifname=lo network.loopback.proto=static network.loopback.ipaddr=127.0.0.1 network.loopback.netmask=255.0.0.0 network.lan.ifname=eth0 tap

-------------------------------------------------------------------------------------

and a normal working one is like this

-------------------------------------------------

Incoming  Received  4.target=0.0.0.0 network.cfg11c8b4.netmask=0.0.0.0 network.ppp.ifname=wwan0 network.ppp.auth_mode=none network.ppp.enabled=1 network.ppp.proto=qmi2 netwo

Incoming  Received  le=wan3 network.cfg0fc8b4.target=0.0.0.0 network.cfg0fc8b4.netmask=0.0.0.0 network.cfg11c8b4.interface=wan4 network.cfg11c8b4.table=wan4 network.cfg11c8b

Incoming  Received  n2 network.cfg0dc8b4.table=wan2 network.cfg0dc8b4.target=0.0.0.0 network.cfg0dc8b4.netmask=0.0.0.0 network.cfg0fc8b4.interface=wan3 network.cfg0fc8b4.tab

Incoming  Received  ork.cfg0bc8b4.interface=wan network.cfg0bc8b4.table=wan network.cfg0bc8b4.target=0.0.0.0 network.cfg0bc8b4.netmask=0.0.0.0 network.cfg0dc8b4.interface=wa

Incoming  Received  network.cfg073777.enable_vlan=1 network.cfg091ec7.device=switch0 network.cfg091ec7.vlan=1 network.cfg091ec7.vid=1 network.cfg091ec7.ports=0 1 2 3 4 netw

Incoming  Received  network.wan3.ifname=wlan0 network.wan3.enabled=0 network.wan3.disabled=1 network.wan3.metric=20 network.cfg073777.name=switch0 network.cfg073777.reset=1

Incoming  Received  proto=none network.wan2.proto=dhcp network.wan2.ifname=eth1 network.wan2.enabled=0 network.wan2.metric=10 network.wan2.disabled=1 network.wan3.proto=dhcp

Incoming  Received  0 network.lan.type=bridge network.lan.proto=static network.lan.ipaddr=192.168.1.1 network.lan.netmask=255.255.255.0 network.wan.ifname=wwan0 network.wan.

Incoming  Received  network.loopback.ifname=lo network.loopback.proto=static network.loopback.ipaddr=127.0.0.1 network.loopback.netmask=255.0.0.0 network.lan.ifname=eth0 tap

----------------------------------------------------------
can anyone point the issue now? 

by anonymous
It's maybe worth defining "Frozen". The things that stop working include the http remote interface to the router and the port forwarding. It does seem to still be able to receive and reply to SMS though.

Also, for context, our issue here is that we have many routers that are having this problem, it tends to happen every few days. They are ALL on the Three.co.uk mobile phone network, they ALL use PPTP VPN. It happens erratically, there is no pattern to time or load and they do not go at the same time. They are in different locations. They are connected to a CCTV system.

We are trying to find a solution to this and we are doing the above diagnostics to try to identify exactly what is going wrong. As we have SMS responses, we're using SMS UCI commands to try to get diagnostics. Maybe there's a better way?

If we could identify the service or resource that is failing, we would then seek to write a locally running script to reboot the router or restart that service.

We have considered remotely polling the router, but we're reluctant to implement this solution as we fear it will have unintended consequences.

We have enabled Auto-reboot on ping and WGet and they are either failing as a service (and therefore not rebooting) or successfully pinging / wgetting and therefore not rebooting. We don't know which.

Any help is appreciated, or alternative approaches.
by anonymous

In a follow up to this, to clarify our objective.

We would like to design a script that will detect the router's failed state and reboot it. 

From the reports above, it seems that the first few rows of the working router are the ones that are missing from the failed one.

i.e.

Incoming  Received  4.target=0.0.0.0 network.cfg11c8b4.netmask=0.0.0.0 network.ppp.ifname=wwan0 network.ppp.auth_mode=none network.ppp.enabled=1 network.ppp.proto=qmi2 netwo

Incoming  Received  le=wan3 network.cfg0fc8b4.target=0.0.0.0 network.cfg0fc8b4.netmask=0.0.0.0 network.cfg11c8b4.interface=wan4 network.cfg11c8b4.table=wan4 network.cfg11c8b

Incoming  Received  n2 network.cfg0dc8b4.table=wan2 network.cfg0dc8b4.target=0.0.0.0 network.cfg0dc8b4.netmask=0.0.0.0 network.cfg0fc8b4.interface=wan3 network.cfg0fc8b4.tab

Incoming  Received  ork.cfg0bc8b4.interface=wan network.cfg0bc8b4.table=wan network.cfg0bc8b4.target=0.0.0.0 network.cfg0bc8b4.netmask=0.0.0.0 network.cfg0dc8b4.interface=wa

Incoming  Received  network.cfg073777.enable_vlan=1 network.cfg091ec7.device=switch0 network.cfg091ec7.vlan=1 network.cfg091ec7.vid=1 network.cfg091ec7.ports=0 1 2 3 4 netw

Incoming  Received  network.wan3.ifname=wlan0 network.wan3.enabled=0 network.wan3.disabled=1 network.wan3.metric=20 network.cfg073777.name=switch0 network.cfg073777.reset=1

So, if we had a script that could detect the absence of any of these conditions, and run it on as a cron task to reboot the router, that would solve our problem, we think. (?).

If so, does anyone know what commands would detect the failed state?

1 Answer

0 votes
by anonymous

Depending on your use of the router, the ping restart maybe a good function. If the router loses connection, the router will restart itself. It will not fix the source of the problem, but is maybe a good workaround.

https://wiki.teltonika.lt/view/Auto_Reboot 

by anonymous
Thanks, we've been using that and it doesn't work. Either the service itself is dead or it is succesfully pinging. (Our hunch is the latter).
by anonymous
Update: by using auto-reboot with the IP of the VPN gateway, this works.

Thanks all for the help.
by

We do experience the same problem. We made ping reboot rule to 8.8.8.8 as fallows

 

it works for 20% o the case when router fails. Router has two boards, board 1 is communication part with GPRS modem, LAN port and WIFI modules, board 2 is with I/O modules. Most of the cases we find the routers on the field with all communication pheriperals working properly but UCI/SSh/local script/ SMS or Call utilies not working. It does not work nothing except  the LAN/WAn and WIFI functionalities. I asume that UCI and all memory is on second board that is failing with unknown reason. By power reset  all return to normal until next fail ( repeating once a few days).  Teltonika Team know about it up to Higher R&D Manager but they do nothing. Their strategy is to keep you busy with stupid solution until warranty expires . With all respect`s, this is not a message Anti-Teltonika it is just the reality