Question

I have an RUT240 configured in bridge mode. Every 60 minutes (pretty much exactly), the Ethernet interface disconnects from my firewall. I have spent many hours testing to be sure this is not a fault with my firewall or wiring. I have concluded that the RUT240 for some unknown reason is causing the Ethernet link to disconnect, them momentarily reconnect.

The modem is running firmware version: RUT2XX_R_00.01.11.3

Can anyone assist me with this problem?

Comments

im getting really poor performance using the new firmware, high ping and drop outs i wasnt seeing before. Anyone else?

---

Hi — Sorry, no; I am not seeing the same performance issue that you have mentioned with the new firmware. Maybe try rolling the firmware back to the previous version, and see if the problem goes away?

---

Any update on this? I still get a disconnect every 40 minutes on latest 1.12.2 software.

---

optymyze — I would suggest creating a new question on this forum, as it sounds like your issue is not the same as this one (otherwise, the firmware update would have fixed it for you).

---

I am experience the same problem. I have firmware version RUT2XX_R_00.01.13 and my router is in passthrough mode. Is there a solution known?

Thanks!

998S	2020-11-05 14:53:57	Port	LAN cable is plugged in
996S	2020-11-05 14:53:51	Port	LAN cable is unplugged
995S	2020-11-05 13:41:44	Port	LAN cable is plugged in
993S	2020-11-05 13:41:39	Port	LAN cable is unplugged
991S	2020-11-05 11:27:26	Port	LAN cable is plugged in
990S	2020-11-05 11:27:20	Port	LAN cable is unplugged
985S	2020-11-04 17:14:22	Port	LAN cable is plugged in
983S	2020-11-04 17:13:01	Port	LAN cable is unplugged
981S	2020-11-04 13:34:32	Port	LAN cable is plugged in
980S	2020-11-04 13:34:26	Port	LAN cable is unplugged

Answer 1

Hello. 

If you have no problems accessing the Web Interface of the device, It would be helpful that you can Change the user and password of your Router to a very generic ones, So we can replicate the issue in one of our routers with a set of files I am going to ask you to send to me via private message.

1.- We need you send a draw diagram of the topology you have implemented. The admin and password of the router 

2.- Please, use the device until it presents the problem and then after that without turning off download a Troubleshoot file, and send it to us (Again all cia private message)

https://wiki.teltonika.lt/view/RUT240_Administration#Troubleshoot

3.- A Backup File of the device.

https://wiki.teltonika.lt/view/RUT240_Administration#Backup

In this way we can advice what would be the right way to proceed and who you will need to contact in case this need further attention.

Comments

jpteltonika —

Hi. Thank you for the follow-up message. I've had the test firmware installed for a couple of days on my RUT240 and it appears to have stopped disconnecting the Ethernet interface every 60 minutes.

Looks like your fixes have worked.

---

@hayden_spence

Thank you very much, We would really appreciate if you can provide a troubleshoot file of the new tests via Private Message.

Kind Regards

---

jpteltonika —

I've sent you the troubleshoot file as requested via private message. Let me know if you need any more information.

---

Im having exactly the same problem with same setup (bridge-mode, LAN cable plugged/unplugged and so on), and its affecting my gaming online and chromecasts pausing Spotify and TuneIn every now and then. Hope for a fix with FOTA soon.

Thanks

---

any update here?

it worked for me after i installed an external antenna, but today i made the mistake and updated to latest firmare, now the reconnects are back:

Mon Jan 18 16:58:35 2021 daemon.notice netifd: ppp_4 (7150): udhcpc: sending renew to xx.xx.xx.xx

Mon Jan 18 16:58:35 2021 daemon.notice netifd: ppp_4 (7150): udhcpc: bind(UDP): Cannot assign requested address

Mon Jan 18 16:58:35 2021 daemon.notice netifd: ppp_4 (7150): udhcpc: sending renew to 0.0.0.0

Mon Jan 18 16:58:35 2021 daemon.notice netifd: ppp_4 (7150): udhcpc: lease of xx.xx.xx.xx obtained, lease time 7200

Mon Jan 18 16:58:36 2021 local1.info hotplug-gsmstate[13849]: envACT: ifupdate

Mon Jan 18 16:58:36 2021 local1.info hotplug-gsmstate[13849]: envDEV: wwan0

Mon Jan 18 16:58:42 2021 local1.notice fwblock[14292]: Started fwblock

Mon Jan 18 16:58:42 2021 local1.notice fwblock[14292]: Applying SSH blocks

Mon Jan 18 16:58:42 2021 local1.notice fwblock[14292]: Applying WebUI blocks

Mon Jan 18 16:58:43 2021 user.notice firewall: Reloading firewall due to ifupdate of ppp_4 (wwan0)

Mon Jan 18 16:58:44 2021 local1.notice fwblock[14382]: Started fwblock

Mon Jan 18 16:58:44 2021 local1.notice fwblock[14382]: Applying SSH blocks

Mon Jan 18 16:58:44 2021 local1.notice fwblock[14382]: Applying WebUI blocks

Mon Jan 18 16:58:45 2021 local1.info hotplug-gsmstate[14431]: envACT: ifupdate

Mon Jan 18 16:58:45 2021 local1.info hotplug-gsmstate[14431]: envDEV: wwan0

Mon Jan 18 16:58:48 2021 user.notice firewall: Reloading firewall due to ifupdate of ppp_4 (wwan0)

Mon Jan 18 16:58:49 2021 local1.notice fwblock[14648]: Started fwblock

Mon Jan 18 16:58:49 2021 local1.notice fwblock[14648]: Applying SSH blocks

Mon Jan 18 16:58:49 2021 local1.notice fwblock[14648]: Applying WebUI blocks

Answer 2

Hello. We have a test Firmware with some fixes. Its a test firmware intended for RUT2XX and RUT9XX. so please don't implement it massively, it's for test purposes only.
 

Can you please implement it and give us feedback?

Rut2XX Test Firmware
https://kaunas.teltonika.lt:444/d/4aec334a630a458fa7ef/

RUT9XX Test Firmware
https://kaunas.teltonika.lt:444/d/8ca288f2e2134d81aec1/

Comments

Thanks. I will test one evening next week. I will have to do outside of operational hours.

---

Will be installing this on a RUT950 shortly - Will advise if it resolves the issue.

---

Hello, thanks for the feedback. If possible, can you send a Troubleshoot File after the tests so we can debug further the behavior of the unit? thanks in advance.

https://wiki.teltonika-networks.com/view/RUT950_Administration#Troubleshoot

---

Sure - I'm not 100% sure its resolved all the problems we were having but definitely appears to have stopped the LAN1 interface bouncing.  However, what we're seeing is that the LAN connectivity now seems to drop around the same time every hour (or every other hour / gradually increasing in time) which is causing the Session Border Controller behind the unit to drop its link to the PBX (and re-establish)

If I sent you a support file, can you assist with investigating that (as it follows exactly the same timeline we'd have previously been seeing the LAN interface dropping) - Where do I send the support file to?

-JT

---

Hi, sure, you can send us the troubleshoot file. But what we had seen before, is that the carriers have the tendency to drop lease connections at a fixed time, some times at 3600 seconds others at 7200 seconds.

This line is typical to be found in troubleshoot files, and this is a parameter that is set by the carrier and sadly there is no way to modify it, unless you have a special simcard from that carrier.

• Fri Jan 24 05:45:39 2020 daemon.notice netifd: ppp_4 (19392): udhcpc: lease of 124.19.79.233 obtained, lease time 7200
• Fri Jan 24 06:45:40 2020 daemon.notice netifd: ppp_4 (19392): udhcpc: lease of 124.19.79.233 obtained, lease time 7200

If you download the LOGs, try to find this line and what is the lease time that your carrier is giving you.

---

Cheers, 7200 seconds here as confirmed by the logs however the issue appears to occur randomly (sometimes it'll reboot an hour after the unit was rebooted - other times it'll be 2, 3, 4 and upto 8-12 hours between connection drops)

What we have noticed however is that if the router's rebooted on the hour, the issue will occur approx the same minutes/seconds past the hour (ie, rebooted router at 8:05:00pm - if we're going to see issues, it'll be at X:05:00 (where X could be anything from 1 hour to 12 hours post reboot) - and it'll repeat at that process (though the "hours between" appears to be random)

Noticed new firmware released overnight - Will apply this in testing tonight if possible.

-JT

---

This is quite annoying and I hope there's a fix. I've several times been disconnected from on-line meetings, from remote support sessions and the like due to the "LAN cable is unplugged"/"LAN cable is plugged in". 

Also my log states a lease time of 7200. Se extract below (IP number masked) 

• Tue Mar 10 14:53:24 2020 daemon.notice netifd: ppp_4 (4090): udhcpc: lease of [IP number] obtained, lease time 7200
• Tue Mar 10 15:53:25 2020 daemon.notice netifd: ppp_4 (4090): udhcpc: lease of [IP number] obtained, lease time 7200
• Tue Mar 10 16:53:25 2020 daemon.notice netifd: ppp_4 (4090): udhcpc: lease of [IP number] obtained, lease time 7200
• Tue Mar 10 17:53:25 2020 daemon.notice netifd: ppp_4 (4090): udhcpc: lease of [IP number] obtained, lease time 7200

That is, 2 hours lease time. But ....
a) it is obtained every hour (not every two hours)
b) the log for the same period only lists three "unplugged"/"plugged in" (not at 15:53)

• 1011|2020-03-10 14:53:37|Port|LAN cable is unplugged
• 1012|2020-03-10 14:53:43|Port|LAN cable is plugged in
• 1015|2020-03-10 16:53:37|Port|LAN cable is unplugged
• 1016|2020-03-10 16:53:43|Port|LAN cable is plugged in
• 1018|2020-03-10 17:53:38|Port|LAN cable is unplugged
• 1019|2020-03-10 17:53:44|Port|LAN cable is plugged in

Analysing the statistics for the last 18 days, I get the following distribution of number hours between "LAN cable in unplugged".

Hours	1	2	3	4	5	6	7	8	9	10	11	12
Count	112	31	28	9	7	3	1	2	1	0	1	1

In 57 % of the cases the "unplugged"/"plugged" in occurs after one hour. In 43 % of the cases at least one hour is skipped. There is no discernable pattern when it comes to, for instance, time of the day or weekday.

---

Hello.

Thanks for the feedback, are you making the tests with the firmware posted here?

Can you please send a private message with the Troubleshoot file to debug it further?

Regards

---

To jpteltonika in response to my comment four days ago.

The information is from a RUT240 (RUT24006E000 with serial number 1105559562) that is used "in production". Hence, it is not used to test the issue. The unit's firmware is RUT2XX_R_00.01.11.3. The unit is used in Bridge mode with mobile data connection as main (and only connection, i.e. no WAN Failover). 

Here's my view on what's causing the issue: 

1) the hardware
2) the software (firmware), or
3) the carrier

In the case of a general hardware or a software issue, you should be able to reproduce it without the need for log files.  

I'm not an expert, but the irregularity in the number of hours between "unplugged" and "plugged in" (sometimes shorter than the lease time, other times longer than the lease time) indicate a hardware or software related issue. 

• Shorter than the lease time: I don't understand why the internet connection would be lost after an hour if the lease time is two hours. 
• Longer than the lease time: Could it be that not all events are being logged? 

Further, perhaps you should consider changing the event text in a future firmware release because unplugging/plugging in the LAN cable isn't what triggers the event log entry. 

Searching the forum, I find one post from 17 July 2019 (Regular LAN port plugged/unplugged events, N.B. for a RUT950), one from 28 December 2019 (Cable unplugged), and one from 6 February 2020 (RUT240: LAN cable unplugged / terrible performance until reboot) all seemingly describing the same issue. This thread was opened more than seven weeks ago. The one from July soon 8 months ago. Hence, should it be a firmware issue, then it's not only affecting the latest version. Should it be a hardware issue, then either not all units are affected or the majority of the users haven't discovered the issue yet.

The router's product page describes it as delivering "high performance for mission-critical cellular communication ..." (my formatting). With such a statement, I believe it's fair to expect Teltonika to prioritizing investigating and solving the issue. Would I have known about the issue discussed in this thread (and in the others referred to above), I wouldn't have bought the unit, nor would I recommend it to be used for "mission-critical cellular communication". 

Should they, as implied in the comment from jpteltonika on 6 March 2020, consider it to be a carrier issue ("the carriers have the tendency to drop lease connections at a fixed time, some times at 3600 seconds others at 7200 seconds"), then they should probably not market it as to be used for "mission-critical cellular communication".

Should it be needed, I can send you log files. If so, please provide info on how to do that via private message. As moderator you should have access to my e-mail address.

Hoping for a quick resolution.

---

Hi again (see post to jpteltonika a few minutes ago): I've now created an account, and see the possibility to send a private message. Posting when logged in you should certainly have access to my e-mail address if you need to contact me directly.

---

Hi Börn, we are not allowed to contact via mail. The information exchange should be performed completely on this platform, it can be in form of posts or private messages.

Regarding the previous comment. When the complete circle of communication relies on multiple parties, as in the case of cellular communications, we only can ensure that we are going to do all our best to fix and understand the issues that are under our complete control.

At this moment we have engineers working to understand what is causing those connection dropouts in this specific case, and that information is obtained via log files, as we don't have control on the sim cards. We need this understanding because we have many success cases where this issues are not happening.

We can offer you better attention if you can contact your local sales manager and provide more insights of your specific projects, so we can offer you a handful number of solutions gained through our experience working with several clients with different clients around the world.

In the meantime we are working in some test firmwares so you can provide us with de feedback needed to help you to overcome this situation.

Best regards

---

To jpteltonika: The troubelshooting files have now been sent.

---

I installed the new firmware (RUT2XX_R_00.01.12) a few days ago and can't see any LAN cable unplugged/plugged in events. So far so good. I'm glad the issue could be resolved.

---

Why are you not updating us with information regarding this problem? I have the RUT2XX_R_00.01.12.1 firmware and it still dont work. 

If no solution comes soon, it goes into the wall. Its frustrating to have paid ~150 Euro for something that doesnt work as it should.

Answer 3

Im having exactly the same problem with same setup (bridge-mode, LAN cable plugged/unplugged and so on), and its affecting my gaming online and chromecasts pausing Spotify and TuneIn. Im just writing here so the Teltonika support team knows that there are probably more affected by this bug.

Comments

Thanks for your contribution. As of this moment, we're all still waiting for Teltonika to release a proper firmware update for this issue. I know nothing more than what is mentioned in this forum topic.

---

We have also exactly the same problem with same setup (bridge-mode, LAN cable plugged/unplugged every  9 minutes past the hour. But only in bridge mode !! / RUT950 - RUT9XX_R_00.06.05.3

Regards 
Markus

---

Can you please implement it and give us feedback?

Rut2XX Test Firmware
https://kaunas.teltonika.lt:444/d/4aec334a630a458fa7ef/

RUT9XX Test Firmware
https://kaunas.teltonika.lt:444/d/8ca288f2e2134d81aec1/

---

With the new Firmware upgrade from https://wiki.teltonika-networks.com/view/RUT950_Firmware_Downloads  RUT9XX_R_00.06.06.1

all up and running

---

Hi!

EDIT: Testing RUT2XX_R_00.01.12.1 right now, will reply later.

EDIT2: The RUT2XX_R_00.01.12.1 did not work either. Should I try the https://kaunas.teltonika.lt:444/d/4aec334a630a458fa7ef/ ? @jpteltonika

@MLehmann: How is it going for you? Did you get rid of the cable plugged/unplugged behavior?

/Gurkan

Answer 4

Has anyone managed to solve this problem with a newer firmware?

I have RUT2XX_R_00.01.12.1 firmware but have not been able to solve the problem. This is becoming a major problem as the music and online gaming get interrupted every now and then.

@Teltonika: Are you still working on the problem?

Answer 5

I wanted to drop in to say I have a Verizon model RUT240 and am experiencing data disconnects  ranging from every 2 minutes to every 60 minutes but with my other modem (GL.iNet x750 with Quectel EP06-A) I experience zero problems with the exact same SIM card, APN, etc. I tested the 1.12.2 firmware today and it did not fix the problem.

I can access the Web UI and everything well, but the data connections disconnects and resets as above. Also, I have great signal at -55.

Comments

I also have drops on the Lan interface also with the newest RUT240 firmware. 

3	2020-06-17 08:16:28 - Web UI: Authentication was succesful fro ...
4	2020-06-17 08:06:28 - Port: LAN cable is unplugged

What can i do?

---

yesterday i did a firmware downgrade and upgrade and reconfigured the device, same problem, disconnect every 60 minutes

1. Sun Jun 28 13:27:30 2020 daemon.notice netifd: ppp_4 (7277): udhcpc: sending renew to xx.xx.xxx.xx
2. Sun Jun 28 13:27:30 2020 daemon.notice netifd: ppp_4 (7277): udhcpc: bind(UDP): Cannot assign requested address
3. Sun Jun 28 13:27:30 2020 daemon.notice netifd: ppp_4 (7277): udhcpc: sending renew to 0.0.0.0
4. Sun Jun 28 13:27:30 2020 daemon.notice netifd: ppp_4 (7277): udhcpc: lease of xx.xx.xxx.xx obtained, lease time 7200
5. Sun Jun 28 13:27:31 2020 local1.info hotplug-gsmstate[22348]: envACT: ifupdate
6. Sun Jun 28 13:27:31 2020 local1.info hotplug-gsmstate[22348]: envDEV: wwan0
7. Sun Jun 28 13:27:37 2020 local1.notice fwblock[22757]: Started fwblock
8. Sun Jun 28 13:27:37 2020 local1.notice fwblock[22757]: Applying SSH blocks
9. Sun Jun 28 13:27:37 2020 local1.notice fwblock[22757]: Applying WebUI blocks
10. Sun Jun 28 13:27:39 2020 daemon.info dnsmasq[10714]: exiting on receipt of SIGTERM
11. Sun Jun 28 13:27:40 2020 user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
12. Sun Jun 28 13:27:40 2020 user.notice dnsmasq: Allowing 127.0.0.0/8 responses
13. Sun Jun 28 13:27:44 2020 daemon.info dnsmasq[23242]: started, version 2.79 cachesize 150
14. Sun Jun 28 13:27:44 2020 daemon.info dnsmasq[23242]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC loop-detect inotify
15. Sun Jun 28 13:27:44 2020 daemon.info dnsmasq-dhcp[23242]: DHCP, IP range 172.16.16.100 -- 172.16.16.249, lease time 12h
16. Sun Jun 28 13:27:44 2020 daemon.info dnsmasq-dhcp[23242]: DHCP, IP range xx.xx.xxx.xx -- xx.xx.xxx.xx, lease time 12h
17. Sun Jun 28 13:27:44 2020 daemon.info dnsmasq[23242]: using local addresses only for domain lan
18. Sun Jun 28 13:27:44 2020 daemon.info dnsmasq[23242]: reading /tmp/resolv.conf.auto
19. Sun Jun 28 13:27:44 2020 daemon.info dnsmasq[23242]: using local addresses only for domain lan
20. Sun Jun 28 13:27:44 2020 daemon.info dnsmasq[23242]: using nameserver 80.120.17.70#53
21. Sun Jun 28 13:27:44 2020 daemon.info dnsmasq[23242]: using nameserver 213.33.99.70#53
22. Sun Jun 28 13:27:44 2020 daemon.info dnsmasq[23242]: read /etc/hosts - 1 addresses
23. Sun Jun 28 13:27:44 2020 daemon.info dnsmasq-dhcp[23242]: read /etc/ethers - 0 addresses
24. Sun Jun 28 13:27:44 2020 user.notice firewall: Reloading firewall due to ifupdate of ppp_4 (wwan0)
25. Sun Jun 28 13:27:45 2020 local1.notice fwblock[23268]: Started fwblock
26. Sun Jun 28 13:27:45 2020 local1.notice fwblock[23268]: Applying SSH blocks
27. Sun Jun 28 13:27:45 2020 local1.notice fwblock[23268]: Applying WebUI blocks
28. Sun Jun 28 13:27:45 2020 local1.info hotplug-gsmstate[23308]: envACT: ifupdate
29. Sun Jun 28 13:27:45 2020 local1.info hotplug-gsmstate[23308]: envDEV: wwan0
30. Sun Jun 28 13:27:47 2020 user.notice firewall: Reloading firewall due to ifupdate of ppp_4 (wwan0)
31. Sun Jun 28 13:27:48 2020 local1.notice fwblock[23407]: Started fwblock
32. Sun Jun 28 13:27:48 2020 local1.notice fwblock[23407]: Applying SSH blocks
33. Sun Jun 28 13:27:48 2020 local1.notice fwblock[23407]: Applying WebUI blocks