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.
0 votes
328 views 14 comments
by anonymous

Today my TRB140 reboots at midnight as every Sunday at 23:59 and from that time I receive a mail

  • Device name - TRB140; Event type - Mobile Data; Event text - Mobile data connected (internal modem)

every hour. I rebooted the device but there is nobody so I could perform only a soft reboot. The only result was that the previous connection times (1:00, 2:00,..) changed to the time of the reboot (7:24, 8:24,..). So every hour I receive a mail form TRB140, from my router (WAN2 is up) from my VOIP gateway (IP has changed)... And also my VPNs are corrupted

In the kernel log I see this repeatedly:

 10:24:56 2023 daemon.info dnsmasq-dhcp[5907]: read /etc/ethers - 0 addresses
Mon Jan  9 10:24:56 2023 kern.info kernel: [10921.884486] br-lan: port 1(eth0) entered disabled state
Mon Jan  9 10:24:57 2023 daemon.notice netifd: bridge 'br-lan' link is down
Mon Jan  9 10:24:57 2023 daemon.notice netifd: Interface 'lan' has link connectivity loss
Mon Jan  9 10:24:57 2023 user.notice firewall: Reloading firewall due to ifup of mob1s1a1_4 (rmnet0)
Mon Jan  9 10:24:57 2023 kern.info kernel: [10923.104180] qcom-emac 7c40000.qcom,emac eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Mon Jan  9 10:24:57 2023 kern.info kernel: [10923.111553] br-lan: port 1(eth0) entered forwarding state
Mon Jan  9 10:24:57 2023 kern.info kernel: [10923.116984] br-lan: port 1(eth0) entered forwarding state
Mon Jan  9 10:24:57 2023 daemon.notice netifd: Network device 'eth0' link is up
Mon Jan  9 10:24:57 2023 daemon.notice netifd: bridge 'br-lan' link is up
Mon Jan  9 10:24:57 2023 daemon.notice netifd: Interface 'lan' has link connectivity
Mon Jan  9 10:24:58 2023 user.notice ddns-scripts[6288]: myddns: pid 6288 started at 2023-01-09 10:24
Mon Jan  9 10:24:59 2023 user.notice ddns-scripts[4808]: myddns: pid 4808 terminated by sigterm at 2023-01-09 10:24
Mon Jan  9 10:24:59 2023 user.notice dnsmasq: dhcp_check(): using cached value: 0
Mon Jan  9 10:25:00 2023 daemon.info dnsmasq[5907]: read /etc/hosts - 4 addresses
Mon Jan  9 10:25:00 2023 daemon.info dnsmasq[5907]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses
Mon Jan  9 10:25:00 2023 daemon.info dnsmasq-dhcp[5907]: read /etc/ethers - 0 addresses
Mon Jan  9 10:25:01 2023 kern.info Mobile data connected (internal modem)

Is there a way how to return my TRB140 back to normal, please? The troubleshooting file is attached. As it appears exactly every hour +1 minute for reboot itself it is not a coincidence

1 Answer

0 votes
by anonymous
Hi,

Would you please clarify the below to help me if I understood you correctly:

Do you want to TRB140 to not to reboot every hour?
What are your desired configurations and expected router behavior?

Regards,
Ramandeep S.
by anonymous

Reset could not be done now as nobody is there. What about sending me a new firmware for the modem as a file? There is an option to upgrade firmware and/or modem via UI. But I do not know if it can automatically reboot after that operation. So if it is a safe step I can do it. Otherwise I have to wait till March :-)

by anonymous
After reflashing FW of the device returned (permanently?) TRB140 to its previous state. No reconnection every hour since than. It is too soon to be sure but I am about to be a little bit optimistic. Thank you for your help and let us hope I will not need you.
by anonymous
Lets observe the unit for next 2-3 days and see if the issue reproduces.
by anonymous

I am sorry to say, you were right. The device reconnected again exactly after 60 hours. That is much better than after 60 minutes but still not optimal. There must be some counter... Couldn't we get to 60 days, please? :-)

by anonymous
As I wrote, the unit reconnected after 60 hours. This happened twice and then - voila - no unexpected reconnection; this positive behaviour even survived the scheduled reboot. I don't know what helped, but the key was reloading the firmware. I hope the problem does not return.