WIKIABOUT

FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

Most popular tags

rut955 rut240 rut950 rutx11 rms vpn to openvpn wifi not sms trb140 firmware connection - ipsec on rutx12 rutx09 modbus
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.

RUT240 (two different devices) no reliable LAN connection

0 votes
772 views 20 comments
by anonymous

I have two RUT240 routers here both not really usable and I'm running out of ideas. They were purchased independently and with several weeks or months in between purchases.

Both are not reliably reachable via the lan interface. This is using the default ip 192.168.1.1 and also when using other ip addresses.

Symptoms are: After booting I can access the web ui from lan, after a few minutes lan ip isn't reachable any more (no ping, no web ui, no ssh). Reboot mostly fixes this.

Using the wifi interface I can still reach those devices even when they're not reachable via lan interface.

I did try:

  • flashing different firmware versions (00.01.14.6, 00.07.01.4, 00.07.02.7) (using the web interface, and also the recovery boot mode)
  • factory reset the devices countless times (via web ui, if possible, and via the reset button > 5s)

Often times I'm not even getting a DHCP lease on the lan interface. Giving a connected device like a laptop a fixed ip address in the correct lan network range still doesn't allow communication then. If reading the arp table of the devices via wifi in this state, the mac addresses show all zeros like after trying to ping a connected lan device with fixed ip from the routers' CLI.

Packet forwarding between wifi and lan is not working. Examples: I connected two laptops for testing, one via lan / ethernet, the other via wifi. Both devices have fixed ip addresses. Running wireshark on both and trying to ping from one to the other shows that arp requests and responses are not flowing correctly between the two devices.

There seems to be a general stability and/or layer 2 problem with those devices?

Other strange things include problems with changing the default password after a factory reset. This has been described somewhere else here in the forum, too: You have to change the default password, which seems to succeed. But you cannot login with the new password afterwards. you CAN still log in with the factory default password.

Seems like a problem with writing to the flash/overlay file system?

I've spent over 8 hours now trying to get these very basic things to work correctly, and with over 25 years of linux / network background I should be able to do this?! I would never rule out stupidity on my side, but I'm really running out of ideas here...

I would urgently need to put those into operation, and they would only be the first two prototypes. Actual usage would be providing a mobile uplink to a connected ip camera and creating a vpn to our datacenter (might be l2tp, openvpn, ...). So nothing really special.

Right now I'm wondering, if our current path (switching to Teltonika from a different vendor because of stability problems there) is a wise move...

So, to conclude: What can I do to make those routers do even the most basic things?

Do you need any more information I can provide?

Christian

by anonymous
Oh yeah, to add to this: Upgrading to the latest firmware via the recovery boot never succeeds, as I always get an error "Incorrect checksum" after uploading the firmware downloaded from here: https://wiki.teltonika-networks.com/wikibase/images/9/9a/RUT2_R_00.07.02.7_WEBUI.bin

The md5 sum of the downloaded file DOES match the checksum published here: https://wiki.teltonika-networks.com/view/Downloads#RUT_Routers

Christian

1 Answer

0 votes
by anonymous

Hello,

The update to the latest RutOS might not be possible due to the older bootloader version, thus, the suggestion is to update to the latest legacy and proceed from here to latter firmware versions.

From what you have described, these seems to be faulty units. You could leave them running for a while for the logs to populate and then download the troubleshoot files from these devices. To generate the files, access router's WebUI, go to System -> Administration > Troubleshoot section and download troubleshoot file from there. Attach the files by editing your initial question. Maybe something will show up.

Best regards,

by anonymous
I've got no way to access the second one in "normal mode" now. Could you point me to the download for the current bootloader so I can update this in recovery mode first?

Christian
by anonymous
Any pointers where to download the most current bootloader to update?

I would need to put at least one unit into the field ASAP...

Christian
by anonymous

Load the latest legacy firmware using bootloader menu and proceed to RutOS from there by updating without Keep settings enabled via WebUI.

by anonymous

I did as instructed above (bootloader => flashing V1.14.6, upgrade via web interface to 7.2.7 without keeping settings).

I was only able to do all of this if connected to the wifi and setting a fixed ip address from the 192.168.1.x network to my wifi adapter.

After the upgrade I've got the same problem: No real connection on the LAN port. No DHCP assigned address becomes available. If setting a fixed ip address from 192.168.1.x network, I can PING the 192.168.1.1, but trying to access the web ui just gives me a "connection reset" error.

Connecting via wifi works.

The kernel log is repeatedly showing this message:

"kern.warn kernel: [  947.202189] br-lan: received packet on eth0 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)"

I have attached the troubleshooting file from one device here: troubleshooting file

I hope there's a quick way to get clarity what's the problem here - my thick fingers, some config problem or a hardware defect (which would be frustrating, to have 2 out of 2 devices dead from the beginning...).

by anonymous
I have forwarded the issue to the development team. In the mean time, would it be possible to get the Wireshark capture of communication between LAN and WIFI devices? It might provide some more details.
by anonymous
Yepp, give me a few minutes. Anything special you're looking for / tests I should perform while capturing?
by anonymous

A first setup of tcpdump outputs is attached here (zipped). The files are:

dhcp-lan-client.pcap: Wireshark file from a Win 10 machine connected via ethernet to the "LAN" port doing a DHCP request. No response received.

dhcp-wifi-client.pcap: Wireshark file from a Win 10 machine connected via wifi doing a DHCP request. Successful (amongst some other traffic in there).

rut240.pcap: Captured with tcpdump on the RUT 240 (-i br-lan) while the Win 10 machine on the RUTs' LAN port was doing DHCP requests. Nothing coming in there looking like DHCP...

Capturing on the RUT with "-i eth0" didn't see any packets (I suppose that's OK as the traffic should be seen by the "br-lan" interface?)

zipped pcaps

by anonymous
> br-lan: received packet on eth0 with own address as source address

Do you have another router on your network with wifi mesh enabled ?
by anonymous
There are 3 MikroTik APs in our network, all of those are configured as dumb regular access points (just bridging wifi to ethernet or a specific VLAN), no mesh or the like.

I cannot rule out other wifi equipment from neighbours around, but generally there's not much wifi around here.
by anonymous

It appears that something is polluting your network. Try a tcpdump -i eth0 -n -v 'src host 192.168.1.1 and dst host 192.168.1.1' and look at the source mac address of these martians.

by anonymous
Well, I don't find anything there. Neither on our local network, nor when sniffing on a laptop connected to the RUTs' wifi (and the RUT not being connected on the LAN side).

Also sniffing on the RUT itself in the tested constellations doesn't give a single packet with src AND dest address of 192.168.1.1.
by anonymous

Could you configure the WAN port of RUT240 as a LAN, as in these instructions, and test if the same behavior repeats on a different physical port?

by anonymous
And with tcpdump -i eth0 -n -v 'ether src host 00:1E:42:42:9E:74 and ether dst host 00:1E:42:42:9E:74' ?

Idem with tcpdump -i eth0 -n -v 'ether src host 00:1E:42:42:9E:74 and ether dst host ff:ff:ff:ff:ff:ff' ?
by anonymous

Configuring the WAN port as additional LAN port gives the same result. Device connected there ahs no connectivity, not getting a DHCP lease etc.

Both tcpdumps show nothing (not a single packet) after running for 10 minutes each.

The log from the RUT 240 still is showing those packets with its' own address as source (00:1e:42:42:9e:74 is the MAC of eth0, which is seen on eth1 - this is with WAN configures as LAN, i.e. eth0, eth1 and wlan0 in br-lan).

Wed Oct  5 16:59:52 2022 daemon.notice netifd: mob1s1a1_4 (25952): udhcpc: started, v1.34.1

Wed Oct  5 16:59:52 2022 daemon.notice netifd: mob1s1a1_4 (25952): udhcpc: broadcasting discover

Wed Oct  5 16:59:52 2022 daemon.notice netifd: mob1s1a1_4 (25952): udhcpc: broadcasting select for 100.124.242.73, server 100.124.242.74

Wed Oct  5 16:59:52 2022 daemon.notice netifd: mob1s1a1_4 (25952): udhcpc: lease of 100.124.242.73 obtained from 100.124.242.74, lease time 7200

Wed Oct  5 16:59:53 2022 daemon.notice netifd: Interface 'mob1s1a1_4' is now up

Wed Oct  5 16:59:53 2022 daemon.info dnsmasq[3883]: reading /tmp/resolv.conf.d/resolv.conf.auto

Wed Oct  5 16:59:53 2022 daemon.info dnsmasq[3883]: using only locally-known addresses for domain test

Wed Oct  5 16:59:53 2022 daemon.info dnsmasq[3883]: using only locally-known addresses for domain onion

Wed Oct  5 16:59:53 2022 daemon.info dnsmasq[3883]: using only locally-known addresses for domain localhost

Wed Oct  5 16:59:53 2022 daemon.info dnsmasq[3883]: using only locally-known addresses for domain local

Wed Oct  5 16:59:53 2022 daemon.info dnsmasq[3883]: using only locally-known addresses for domain invalid

Wed Oct  5 16:59:53 2022 daemon.info dnsmasq[3883]: using only locally-known addresses for domain bind

Wed Oct  5 16:59:53 2022 daemon.info dnsmasq[3883]: using only locally-known addresses for domain lan

Wed Oct  5 16:59:53 2022 daemon.info dnsmasq[3883]: using nameserver 139.7.30.125#53

Wed Oct  5 16:59:53 2022 daemon.info dnsmasq[3883]: using nameserver 139.7.30.126#53

Wed Oct  5 16:59:54 2022 user.warn mwan3-hotplug[25913]: hotplug called on mob1s1a1 before mwan3 has been set up

Wed Oct  5 16:59:55 2022 daemon.info ledman[4143]: Failed to lookup for network.interface.wan object

Wed Oct  5 16:59:55 2022 daemon.info ledman[4143]: Failed to lookup for network.interface.wan6 object

Wed Oct  5 16:59:57 2022 user.notice firewall: Reloading firewall due to ifup of mob1s1a1 (wwan0)

Wed Oct  5 17:00:01 2022 user.notice dnsmasq: dhcp_check(): using cached value: 0

Wed Oct  5 17:00:02 2022 daemon.info dnsmasq[3883]: read /etc/hosts - 4 addresses

Wed Oct  5 17:00:02 2022 daemon.info dnsmasq[3883]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses

Wed Oct  5 17:00:02 2022 daemon.info dnsmasq-dhcp[3883]: read /etc/ethers - 0 addresses

Wed Oct  5 17:00:03 2022 daemon.info unhandler[1927]: *Unsolicited id: 1-1 | msg: '+CREG: 1,"BBB2","14ABF08",7'

Wed Oct  5 17:00:03 2022 daemon.info unhandler[1927]: *Unsolicited id: 1-1 | msg: '+CGREG: 1,"BBB2","14ABF08",7'

Wed Oct  5 17:00:03 2022 user.warn mwan3-hotplug[26475]: hotplug called on mob1s1a1_4 before mwan3 has been set up

Wed Oct  5 17:00:04 2022 daemon.info unhandler[1927]: *Unsolicited id: 1-1 | msg: '+CREG: 1,"BBB2","14ABF15",7'

Wed Oct  5 17:00:04 2022 daemon.info unhandler[1927]: *Unsolicited id: 1-1 | msg: '+CGREG: 1,"BBB2","14ABF15",7'

Wed Oct  5 17:00:04 2022 user.notice firewall: Reloading firewall due to ifup of mob1s1a1_4 (wwan0)

Wed Oct  5 17:00:07 2022 user.notice dnsmasq: dhcp_check(): using cached value: 0

Wed Oct  5 17:00:08 2022 daemon.info dnsmasq[3883]: read /etc/hosts - 4 addresses

Wed Oct  5 17:00:08 2022 daemon.info dnsmasq[3883]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses

Wed Oct  5 17:00:08 2022 daemon.info dnsmasq-dhcp[3883]: read /etc/ethers - 0 addresses

Wed Oct  5 17:00:09 2022 kern.info Mobile data connected (internal modem)

Wed Oct  5 17:00:09 2022 kern.info Joined FDD LTE network (internal modem)

Wed Oct  5 17:00:09 2022 kern.info Connected to vodafone.de 1&1 operator (internal modem)

Wed Oct  5 17:00:13 2022 daemon.info hostapd: wlan0: STA 5c:80:b6:70:cf:d3 IEEE 802.11: authenticated

Wed Oct  5 17:00:13 2022 daemon.info hostapd: wlan0: STA 5c:80:b6:70:cf:d3 IEEE 802.11: associated (aid 1)

Wed Oct  5 17:00:13 2022 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 5c:80:b6:70:cf:d3

Wed Oct  5 17:00:13 2022 kern.notice WiFi client connected: 5C:80:B6:70:CF:D3

Wed Oct  5 17:00:13 2022 daemon.info hostapd: wlan0: STA 5c:80:b6:70:cf:d3 RADIUS: starting accounting session C78C33E31D2EDA68

Wed Oct  5 17:00:13 2022 daemon.info hostapd: wlan0: STA 5c:80:b6:70:cf:d3 WPA: pairwise key handshake completed (RSN)

Wed Oct  5 17:00:14 2022 kern.warn kernel: [ 7683.074583] net_ratelimit: 27 callbacks suppressed

Wed Oct  5 17:00:14 2022 kern.warn kernel: [ 7683.074606] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:22 2022 kern.notice Authentication was successful from HTTP 192.168.1.17

Wed Oct  5 17:00:22 2022 daemon.err uhttpd[2331]: vuci: accepted login for admin from 192.168.1.17

Wed Oct  5 17:00:22 2022 kern.warn kernel: [ 7690.963466] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:22 2022 kern.warn kernel: [ 7691.062411] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:22 2022 kern.warn kernel: [ 7691.071279] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:22 2022 kern.warn kernel: [ 7691.081195] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:22 2022 kern.warn kernel: [ 7691.091227] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:22 2022 kern.warn kernel: [ 7691.104982] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:22 2022 kern.warn kernel: [ 7691.113728] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:22 2022 kern.warn kernel: [ 7691.130732] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:22 2022 kern.warn kernel: [ 7691.139494] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:22 2022 kern.warn kernel: [ 7691.149503] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:28 2022 kern.warn kernel: [ 7697.666372] net_ratelimit: 5 callbacks suppressed

Wed Oct  5 17:00:28 2022 kern.warn kernel: [ 7697.666394] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:31 2022 kern.notice Authentication was successful from HTTP 192.168.1.17

Wed Oct  5 17:00:31 2022 daemon.err uhttpd[2331]: vuci: accepted login for admin from 192.168.1.17

Wed Oct  5 17:00:31 2022 kern.warn kernel: [ 7699.852206] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:31 2022 kern.warn kernel: [ 7699.955366] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:31 2022 kern.warn kernel: [ 7699.964279] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:31 2022 kern.warn kernel: [ 7699.974157] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:31 2022 kern.warn kernel: [ 7699.984221] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:31 2022 kern.warn kernel: [ 7699.994253] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:31 2022 kern.warn kernel: [ 7700.004319] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:31 2022 kern.warn kernel: [ 7700.018134] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:31 2022 kern.warn kernel: [ 7700.026847] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:34 2022 kern.warn kernel: [ 7703.107295] net_ratelimit: 6 callbacks suppressed

Wed Oct  5 17:00:34 2022 kern.warn kernel: [ 7703.107317] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:35 2022 kern.warn kernel: [ 7704.578665] br-lan: received packet on eth1 with own address as source address (addr:00:1e:42:42:9e:74, vlan:0)

Wed Oct  5 17:00:44 2022 daemon.info unhandler[1927]: *Unsolicited id: 1-1 | msg: '+CREG: 2'

Wed Oct  5 17:00:44 2022 daemon.info unhandler[1927]: *Unsolicited id: 1-1 | msg: '+CGREG: 2'

Wed Oct  5 17:00:45 2022 kern.notice Authentication was successful from HTTP 192.168.1.17

Wed Oct  5 17:00:45 2022 daemon.err uhttpd[2331]: vuci: accepted login for admin from 192.168.1.17

Wed Oct  5 17:00:53 2022 user.notice qmux_track: Connection lost.

by anonymous

> br-lan: received packet on eth1 with own address as source address

It would be interesting to see the content of such packets:

tcpdump -i eth1 -n -v -s 0 -w capeth1.pcap 'ether src host 00:1E:42:42:9E:74 and ether dst host 00:1E:42:42:9E:74'

and post the capeth1.pcap file.

by anonymous

After a reboot it's behaving even stranger:

Even via wifi I DO get an ipv4 address by DHCP, and CAN ping th RUT (@192.168.1.1).

I CANNOT for the sake of me (tested using two laptops) open the web UI or SSH into the RUT anymore. I noticed that the LEDs on the LAN and WAN ports go off occasionally (regardless if something is connected there or not).

See attached sniff from a connected laptop. You can see echo req/replies, and an SSH and HTTP connection attempt. Both are not getting past the TCP syn/ack stage...

rut240-ping-no-connections.pcap

Trying to reset the unit once more to gain access...

by anonymous
After factory resetting the unit once more, I can reach it again.

Will postpone further tests until tomorrow, have other work to finish. Will get back with more results...
by anonymous
Similar output in the logs might be due to hardware failure, thus, if none of the suggestions produce acceptable device operation, simply return the router for warranty repair.
by anonymous
Yeah, I give up about this one. I just tried to get some tcpdump again, but just cannot SSH in again (ping working, web ui not, too) via wifi and LAN.

I'll return this for replacement.

Thanks for your time!