T3-TB and TSTAT-10 Port 502 Refuses all connections on WiFi

I believe there is a bug in the firmware (currently running latest) of the WiFi devices. After ending the TCP session with these devices, sometimes they will no longer allow new connections to port 502 through WiFi until they’re power cycled. As such any external modbus polling (or T3000) will cease to function if it is routed through WiFi. However, the wired PHY on the T3-TB (on port 502) and the RS-485 PHY on the TSTAT-10 remain fully functional and are capable of communicating with T3000 and external modbus masters.

I first noticed this issue when I was having packet loss issues with the new wireless AP’s we installed in our new office, this issue has been largely corrected. It appears to only ever occur after a TCP session is terminated (through either RST or FIN,ACK). Below is a snippet from wireshark capture from yesterday, as you can see I closed my modbus master (FIN ACK sequence. Capture 322), about twenty minutes later I started it again and it sent out SYN packets as per normal but the controllers and thermostat responded with an RST, ACK. No amount of retries will successfully create a new TCP session to the devices until they’re powered cycled or rebooted through T3000 (through hardwire).

TemcoTCPLockoutFiltered.pcapng (46.2 KB)

This is quite the problem for me because there are 26 controllers mounted inside of enclosures 10+ feet off of the ground and 26 thermostats that all need to be power cycled periodically when this issue occurs.

Any assistance in resolving this would be most appreciated.

I will also mention that polling is set to a 10s interval with block reads and block writes through modbus.

Lijun will check and report back.

There’s a known issue with the wifi connections. they cannot handle a large number of packets in a short time. If you are running into the issues described make sure you do ALL polling using the block read and write commands. And as always be sure to update the device firmware.


We are having a similar problem. Our configuration it a Tstat10_wifi which is being read/written to via MODBUS TCP by a third party PLC. After a random period of time the Tstat10 MODBUS interface fails. The Tstat10 does respont to aping and can be found on the network at the IP address it was given, however, a power down restart is required to access it via wifi.

1 Like

this is a known issue. please update the Tstat firmware and switch all reads and writes to block mode.

Or reduce the polling rate. the WiFi module does work but at a certain point it cannot keep up and will lock up.


The T3000 software indicated that the firmware was updated successfully. Now the Tstat10 flashes the screen continually but will not complete the boot cycle. Is there way to recover?


Please search this forum for key word “unbrick”. basically you cycle power and flash again in the first few seconds after power up.


An update.

I am able to replicate this issue somewhat reliably. If after several hours of polling the TCP session ends, the devices become non responsive to new TCP sessions. I also noticed that a few devices randomly came back, some were dead for a few hours, others for days.
They then died again after I closed the session to change some configuration to my polling.

Currently I am polling a block of 20 registers at 30s intervals but the devices will still stop listening for TCP connections after a session is ended. The devices are running the latest firmware. The polling rate is extremely slow with very few registers actually being requested and yet these devices are still failing…

Fandu will study this and report back ASAP.

Wifi connectivity is a know issue under heavy polling with the current WiFi module. we have a new module making it’s way into production now.

If you have a wireshark log of your network traffic perhaps we can spot something there.


We have set up several wifi devices and are trying to replicate this phenomenon, and we will report back in time.

The maximum number of TCP connections supported by our module is 3, so you can confirm that you have disconnected the old connection when opening a new one. We did not find problems with the modbus software for routine testing.