Question

Hello

The goal is to operate 2 RUTX50 with zerotier as virtual switch in bridge mode to connect "dumb" devices via 4/5G that have no capability to install some VPN on it.

device 1     <--->    br-lan RUTX50_1 <---> 4/5G <---> br-lan RUT50_2 <---> device 2     (br-lan members: zt+ and eth0)

172.19.31.12/16    172.19.31.102/16                           172.19.31.101/16             172.19.31.11/16

Setup was done according the howto on the Teltonika Wiki page. Routing and switchings seems OK, device 1 and device 2 ar pingable from any zerotier address, but:

I am experiencing on RUTX50 a lot of dropped packets on the RX side:

wwan0     Link encap:Ethernet  HWaddr 76:3D:D6:CC:87:42
          inet6 addr: fe80::743d:d6ff:fecc:8742/64 Scope:Link
          UP BROADCAST RUNNING NOARP MULTICAST  MTU:31744  Metric:1
          RX packets:34248 errors:0 dropped:33594 overruns:0 frame:0
          TX packets:23926 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8482248 (8.0 MiB)  TX bytes:2502828 (2.3 MiB)

pinging the RUTX50 gives lost replies.

even changed the VPN configuration from zerotier to OpenVPN, same effect, then factory reset and only traffic between the 2 RUTX50, same effect without any VPN solution, my conclusion not the VPN is the cause!

4/5G signals are OK

root@rutx50101:~# gsmctl -q
RSSI: -63
RSRP: -90
SINR: 3
RSRQ: -12

I do not understand the value of SINR: 3

Changing position and changing Providers between Sunrise and Swisscom gives no remedy.

Firmware: RUTX_R_00.07.04.1 or RUTX_R_00.07.04.2 same effect

After longtime of testing and probing around, I decided to make the same setup with 2 RUTX12 and Zerotier and what miracle, no dropped packets, no loss of pings.

As there are in one week two firmware upgrades for the RUTX, is the development of the RUTX50 really ready for real operation or does Teltonika use the users as betatester? Or what I am doing wrong? Do we need a special modem configuration or even a new modem firmware?

by the way zerotier actually is release 1.10.6, Teltonikas package has 1.10.1 so I had to make a workaround for a zerotier fix:

2023-02-15 -- Version 1.10.3

• Fix for duplicate paths in client. Could cause connectivity issues. Affects all platforms.

I had to put a config.local on the RUTX50, quite a bit tricky as the /var/lib/zerotier-one directory goes after reboot in /tmp/lib/zerotier.....

If anybody needs the hint, let me know and we will open another discussion.

Any help is appreciated, regards Marco

---

Hi Daumantas

I have the same configuration on the RUTX50 und RUTX12, rame Provider.

Normal configuration to connect to the internet and afterwords installed zerotier,then buit the bridge.

I had to add on both types to add a local.conf for zerotier, otherwise zerotier is flapping between different ways to the other zerotier partners with the effect, that ping times had 5-6 times 35ms and then 5-6 times 230ms, after I applied the local.conf it got stable about 35ms ping time.

Comments

Hello

any news?

Regards

Answer 1

Hello,

  

I will ask you to provide a troubleshoot file from the device. This can be done by navigating to System → Administration → Troubleshoot. the file can be attached to the original post and will only be visible to Teltonika moderators.

wwan0 interface is not used on RUTX50. Instead, please refer to qmimux0, as this is the mobile interface. So the issue is most likely somewhere else. If your configuration on RUTX12 any different from the RUTX50?

  

Best regards,
DaumantasG

Comments

here is the local.conf for zerotier

{
        "physical": {
            "172.19.0.0/16": { "blacklist": true }
    
        },
        "settings": {
            "interfacePrefixBlacklist": [ "ztrta5dc2t", "br-lan" ],
            "primaryPort": 9993,
            "portMappingEnabled": false,
            "allowSecondaryPort": false,
            "allowTcpFallbackRelay": false
            }
    }

---

and here the actual ping results:

64 bytes from 172.19.1.1: seq=21 ttl=64 time=41.294 ms
64 bytes from 172.19.1.1: seq=22 ttl=64 time=38.739 ms
64 bytes from 172.19.1.1: seq=26 ttl=64 time=37.708 ms
64 bytes from 172.19.1.1: seq=27 ttl=64 time=35.568 ms
64 bytes from 172.19.1.1: seq=28 ttl=64 time=44.375 ms
64 bytes from 172.19.1.1: seq=29 ttl=64 time=27.244 ms
64 bytes from 172.19.1.1: seq=30 ttl=64 time=35.883 ms
64 bytes from 172.19.1.1: seq=34 ttl=64 time=34.906 ms
64 bytes from 172.19.1.1: seq=35 ttl=64 time=43.858 ms
64 bytes from 172.19.1.1: seq=36 ttl=64 time=42.610 ms
64 bytes from 172.19.1.1: seq=37 ttl=64 time=44.269 ms
64 bytes from 172.19.1.1: seq=38 ttl=64 time=34.014 ms
64 bytes from 172.19.1.1: seq=39 ttl=64 time=51.797 ms
64 bytes from 172.19.1.1: seq=42 ttl=64 time=1028.280 ms
64 bytes from 172.19.1.1: seq=43 ttl=64 time=35.501 ms
64 bytes from 172.19.1.1: seq=44 ttl=64 time=34.533 ms
64 bytes from 172.19.1.1: seq=45 ttl=64 time=32.308 ms
64 bytes from 172.19.1.1: seq=46 ttl=64 time=38.887 ms

time is variing and packets lost

---

Hi,

As DaumantasG mentioned, wwan0 on RUTX50 will show a lot of dropped packets on the received side. This is normal in this case, because RUTX50 uses qmimux0 interface.Qmimux0 interface in your troubleshoot file shows that no packets are actually dropped:

So the issue may be somewhere else.

However, as you have already mentioned, the SINR can also be the issue here, since the troubleshoot reports a bad SINR (even -nan):

This is one of the potential issues, as SINR also results in lost packets due to noise. You can refer for signal strength recommendations here.

Otherwise, could you download backup (so that you can revert back later on), and restore the device to factory defaults. Could you check if any of the pings fail with the default settings? What are the results?

Kind Regards,

Andzej