I’ve now had 4 instances where I can no longer access one of our TSW202 devices. THe GUI becomes unavailable and devices connected to the switch become unavailable on the network.
The network is simple. 2x TSW 202 switches. All ports expect port 7 on default vlan. Port 7 is untagged on VLAN 10 and port 1 is also tagged on VLAN 10. The 2 switches are connected via port 1. One of the switches is connected to a RUTX50 which provides DHCP/DNS and internet access. It also facilitates a wireguard connection back to the office.
Any ideas why it periodically crashes and makes the devices connected to it unavailable?
HAs anyone else experienced instability with the TSW202?
Same thing has happened twice on my new TSW202 in the last few days. It becomes unresponsive but I can access it again by replugging the ethernet cable.
Somehow all ports become blocked. Spanning tree is disabled. I’m running TSW2_R_00.01.02.2.
Can you please upgrade the firmware and let me know if the issue persists?
You can upgrade the firmware from the WebUI, from the System > Firmware section.
You can download the firmware files from here.
Still having loads of issues with these devices. I honestly feel like I am wasting hours upon hours beta testing a product that isn’t fit for purpose. So much so that we are reverting back to using Netgear GS110TPv3 which aren’t “industrial” spec.
I can now reliably say that the v1.02.2 firmware simply locks up the GUI/CLI at some stage and becomes completely unresponsive to SNMP monitoring or web gui /ssh login. On occasion this also locks up comms with any attached device and at other times it seems to allow communication still so the network appears to be working.
On the v1.03.1 firmware the GUI doesn’t lockup, however it becomes so laggy it may as well do. This too causes SNMP to complain that the device is offline. I found that the uhttpd service daemon takes up way too much CPU with HTTPS active. Turning off https under “Administration - Access control” causes the gui to come back to a responsive state. Perhaps there is a bug there.
As per the original post, the network design is about as simple as you can get it.
2x TSW202 switches connected via port 1. The upmast switch is connected to a RUTX50 router. There is a vlan on the switches to segregate port 7 (untagged on vlan 10) and port 1 for both switches is untagged on vlan 1 and tagged on vlan 10.
No fancy features are enabled. No STP, No Profinet, no lldp, no OPC, no mrp, no dhcp (that is handled by the rutx50), no qos etc
If you are a customer thinking about the TSW202 for your applications, don’t get them until this post is about a year old. Perhaps by then the switches will be usable for something other than a paperweight.
If you work for Teltonika, then what on earth were you thinking releasing such an unreliable product before it is ready! Shame on you!
I have sent you a form to fill out. Once completed, I will contact you privately regarding this issue. Please use ticket ID “9977” when filling out the form.
I’m also still seeing this with the latest firmware. When it happens I set the downstream switch port down and up again. Them I’m able to login and reboot the switch. Perhaps the other ports would also start working after downing them momentarily but I haven’t tested it.
Our development team is continuing to investigate the issue, potential causes, and solutions. As mentioned earlier, I will provide an update as soon as I receive any feedback from them.
