TerraMaster Forum

I have an F2-423. I have recently noticed that the LAN LED in the front and the RJ-45 link light on the back are blinking non-stop 24/7 suggesting constant NIC traffic. It didn't use to be like this in the past when I first installed the NAS - that I remember for sure. It has changed a couple of houses since then and had a drive failure/replacement I can't pinpoint exactly when that started happening.
Everything is working fine and the Resource Monitor in TOS shows a small 0.003-0.05 MB/s traffic which occasionally drops to 0 and picks back up again. I couldn't figure out which app or service causes the traffic. Even when the resource monitor shows 0 traffic the LED and NIC are still blinking.
It is connected to a Flint 3 router which itself is behind the ISP router. Disconnected my router from the internet and nothing changed suggesting the traffic is local. Connected it directly to the ISP router and the same thing happens. So it isn't the Flint either.
Basically everything is working as intended but that incessant LAN traffic is odd. I understand it has to send some traffic regularly for local network maintenance but it used to be occasional in the past as expected. Disabling all my running apps and services like Tailscale and media server didn't change anything.
Any ideas/suggestions?

UPDATE: After spending half a day troubleshooting, capturing traffic, talking to Terramaster support etc..I believe the constant blinking doesn't have to do with traffic at all. I monitored with Wireshark and all is fine. Also installed nethogs and it showed only the tiny traffic from my current SSH session. This doesn't look like actual traffic hitting the NIC. I suspect a TOS update changed the behaviour of the LED at some point to be always blinking when connected. Can anyone else confirm that is normal behaviour?

section94 wrote: ↑22 Sep 2026, 18:19

Thank you for sharing your detailed troubleshooting steps and update. In general, continuous LAN LED blinking can be related to several hardware and network-level factors:

• Hardware/PHY-Level Triggers: The front LAN LED and the rear RJ-45 activity lights are driven directly by the network controller's physical layer (PHY). Any low-level packet or electrical activity hitting the physical port can trigger the LED, even if the packet is filtered at the interface level and does not register as active throughput in the TOS Resource Monitor or tools like nethogs.

• Background Broadcast & Multicast Traffic: Modern local networks generate a steady stream of background packets (such as ARP requests, mDNS, SSDP, UPnP, or router discovery packets) from routers, PCs, mobile devices, and smart home appliances.

• Network Environment Changes: Modifications to the network topology, changing routers, or adding new active clients to the LAN can alter the frequency of background packet exchanges.

Could you also let us know your specific TOS version? We will continue to keep an eye on this situation and attempt to reproduce the behavior you described in our test environment. If there are any further findings or updates, we will let you know.

EriChan wrote: ↑23 Sep 2026, 10:47

section94 wrote: ↑22 Sep 2026, 18:19

Thank you for sharing your detailed troubleshooting steps and update. In general, continuous LAN LED blinking can be related to several hardware and network-level factors:

• Hardware/PHY-Level Triggers: The front LAN LED and the rear RJ-45 activity lights are driven directly by the network controller's physical layer (PHY). Any low-level packet or electrical activity hitting the physical port can trigger the LED, even if the packet is filtered at the interface level and does not register as active throughput in the TOS Resource Monitor or tools like nethogs.

• Background Broadcast & Multicast Traffic: Modern local networks generate a steady stream of background packets (such as ARP requests, mDNS, SSDP, UPnP, or router discovery packets) from routers, PCs, mobile devices, and smart home appliances.

• Network Environment Changes: Modifications to the network topology, changing routers, or adding new active clients to the LAN can alter the frequency of background packet exchanges.

Could you also let us know your specific TOS version? We will continue to keep an eye on this situation and attempt to reproduce the behavior you described in our test environment. If there are any further findings or updates, we will let you know.

My specific TOS version is 6.0.794-01324
I also connected the NAS directly to my desktop PC with no other devices involved just to see what happens. The same non-stop blinking occurs.

Hello,

Thank you for such a detailed troubleshooting report. Based on everything you've shared — no abnormal traffic in the Resource Monitor, Wireshark, or nethogs, and the device is functioning perfectly — we can preliminarily conclude that this is not a device fault. There is nothing to worry about.

Regarding the constantly blinking LED: the front LAN LED and the rear RJ-45 activity light are driven directly by the NIC's physical layer (PHY). Any signal reaching the physical port will trigger the LED — including the constant background broadcast/multicast packets on modern local networks (ARP, mDNS, SSDP, UPnP, etc.) and system-level broadcasts from the peer device's own network adapter, even on a direct PC connection. These packets are filtered at the interface level and never register as throughput in TOS, so the LED blinks while the Resource Monitor shows nothing. This is normal behavior.

Since the blinking persists even with a direct PC connection, we'd suggest one decisive test: with the NAS directly connected to the PC, temporarily disable the network adapter on the PC (keep the cable attached) and observe the LED:

- If the LED stops blinking: the blinking comes from background broadcasts sent by the peer device, which is completely normal;
- If the LED keeps blinking: this points to PHY-level signaling or the LED driver itself, and we will investigate further on that basis.

If convenient, please also run the following two commands in the Terminal app in TOS and share the output for cross-verification:

1. (to check whether the interface repeatedly goes link up/down);
2. (to check whether error packet / CRC error counters are continuously increasing).

Your TOS version (6.0.794-01324) has been recorded, and our test team is reproducing this behavior in our lab. We will update this thread as soon as we have any findings.

Thank you for your patience and cooperation!

Disabling the network adapter in Windows while connected indeed stops the blinking, same as disconnecting the cable. Though by you responses and willingness to reproduce it doesn't seem like a non stop blinking should be the default behaviour. Also I don't think this is due to continuous broadcast messages. If broadcasts were causing so much continuous traffic this would indicate a broadcast storm/loop and it would show immediately in Wireshark not to mention it would wreck network performance. Wireshark when capturing the port on the router which the NAS is connected to only shows occasional ARP messages which is normal.

More importantly, other devices connected to the same router like my desktop or laptop blink as expected intermittently or continuously only when there is actual heavy activity. They too would receive the broadcasts and blink non-stop. ONLY the NAS blinks non-stop without doing anything. Anyway here is the output you requested. Let me know if it helps:

section94@TNAS:/# dmesg | grep -i eth
[ 0.438032] igb: Intel(R) Gigabit Ethernet Network Driver
[ 0.438045] Intel(R) 2.5G Ethernet Linux Driver
[ 0.510887] igc 0000:01:00.0 eth0: MAC: 6c:bf:b5:03:df:88
[ 0.584476] igc 0000:02:00.0 eth1: MAC: 6c:bf:b5:03:df:89
[ 0.584646] i40e: Intel(R) Ethernet Connection XL710 Network Driver
[ 0.584679] iavf: Intel(R) Ethernet Adaptive Virtual Function Network Driver
[ 0.584690] Intel(R) Ethernet Switch Host Interface Driver
[ 0.584743] ice: Intel(R) Ethernet Connection E800 Series Linux Driver
[ 0.585293] usbcore: registered new interface driver cdc_ether
[ 0.600324] l2tp_eth: L2TP ethernet pseudowire support (L2TPv3)
[ 17.792155] igc 0000:01:00.0 eth0: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX/TX
[ 17.792188] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 371.579633] igc 0000:01:00.0 eth0: NIC Link is Down
[ 401.647026] igc 0000:01:00.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 475.279473] igc 0000:01:00.0 eth0: NIC Link is Down
[ 754.752451] igc 0000:01:00.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[ 790.875204] igc 0000:01:00.0 eth0: NIC Link is Down
[ 808.400368] igc 0000:01:00.0 eth0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[ 826.169889] igc 0000:01:00.0 eth0: NIC Link is Down
[ 865.471900] igc 0000:01:00.0 eth0: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX/TX

section94@TNAS:/# ethtool -S eth0
NIC statistics:
rx_packets: 5497
tx_packets: 8509
rx_bytes: 1120032
tx_bytes: 6622935
rx_broadcast: 212
tx_broadcast: 176
rx_multicast: 1123
tx_multicast: 285
multicast: 1123
collisions: 0
rx_crc_errors: 0
rx_no_buffer_count: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 0
tx_single_coll_ok: 0
tx_multi_coll_ok: 0
tx_timeout_count: 0
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 643
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_long_byte_count: 1120032
tx_dma_out_of_sync: 0
tx_smbus: 0
rx_smbus: 0
dropped_smbus: 0
os2bmc_rx_by_bmc: 0
os2bmc_tx_by_bmc: 0
os2bmc_tx_by_host: 0
os2bmc_rx_by_host: 0
tx_hwtstamp_timeouts: 0
tx_hwtstamp_skipped: 0
rx_hwtstamp_cleared: 0
tx_lpi_counter: 0
rx_lpi_counter: 0
qbv_config_change_errors: 0
rx_errors: 0
tx_errors: 0
tx_dropped: 0
rx_length_errors: 0
rx_over_errors: 0
rx_frame_errors: 0
rx_fifo_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_queue_0_packets: 937
tx_queue_0_bytes: 551458
tx_queue_0_restart: 0
tx_queue_1_packets: 4084
tx_queue_1_bytes: 3754768
tx_queue_1_restart: 0
tx_queue_2_packets: 2571
tx_queue_2_bytes: 1784835
tx_queue_2_restart: 0
tx_queue_3_packets: 917
tx_queue_3_bytes: 485450
tx_queue_3_restart: 0
rx_queue_0_packets: 1400
rx_queue_0_bytes: 312668
rx_queue_0_drops: 0
rx_queue_0_csum_err: 0
rx_queue_0_alloc_failed: 0
rx_queue_1_packets: 807
rx_queue_1_bytes: 342842
rx_queue_1_drops: 0
rx_queue_1_csum_err: 0
rx_queue_1_alloc_failed: 0
rx_queue_2_packets: 1617
rx_queue_2_bytes: 198167
rx_queue_2_drops: 0
rx_queue_2_csum_err: 0
rx_queue_2_alloc_failed: 0
rx_queue_3_packets: 1673
rx_queue_3_bytes: 244367
rx_queue_3_drops: 0
rx_queue_3_csum_err: 0
rx_queue_3_alloc_failed: 0

Thank you for the detailed testing and data — it's very valuable, and your analysis is correct: since other devices on the same router do not blink constantly and Wireshark shows only occasional ARP, background broadcasts alone cannot explain this behavior. We'll set that theory aside.

However, your dmesg output reveals an important new finding: between roughly 6 and 14 minutes after boot, eth0 went through multiple link down/up cycles, and the negotiated speed jumped repeatedly between 2500 Mbps → 1000 Mbps → 100 Mbps → 2500 Mbps. Every link renegotiation triggers the activity LED. The drop to 100 Mbps in particular is a classic indicator that the cable, connector, or port quality may not meet 2.5GbE requirements.

Could you please help confirm two things:

1. Does that time window (about 6–14 minutes after boot) coincide with your cable-switching tests between the routers and the direct PC connection? If so, this is expected. But if the link renegotiates or downshifts on its own without any intervention, please try a high-quality cable (Cat6 recommended) first and observe whether the blinking improves;
2. Please run a quick 60-second quantitative test while the device is idle: in the Terminal app, run ethtool -S eth0 | grep rx_packets, note the value, wait 60 seconds, and run it again. If the counter barely changes while the LED still blinks constantly, that confirms the blinking is unrelated to actual traffic and points to the LED driver behavior itself — we will then submit this as formal evidence to our R&D team for in-depth analysis.

Regarding the ethtool statistics, rest assured: CRC and all error counters are zero, so your network environment is healthy.

CursaYang wrote: ↑25 Sep 2026, 19:35 Thank you for the detailed testing and data — it's very valuable, and your analysis is correct: since other devices on the same router do not blink constantly and Wireshark shows only occasional ARP, background broadcasts alone cannot explain this behavior. We'll set that theory aside.

However, your dmesg output reveals an important new finding: between roughly 6 and 14 minutes after boot, eth0 went through multiple link down/up cycles, and the negotiated speed jumped repeatedly between 2500 Mbps → 1000 Mbps → 100 Mbps → 2500 Mbps. Every link renegotiation triggers the activity LED. The drop to 100 Mbps in particular is a classic indicator that the cable, connector, or port quality may not meet 2.5GbE requirements.

Could you please help confirm two things:

1. Does that time window (about 6–14 minutes after boot) coincide with your cable-switching tests between the routers and the direct PC connection? If so, this is expected. But if the link renegotiates or downshifts on its own without any intervention, please try a high-quality cable (Cat6 recommended) first and observe whether the blinking improves;
2. Please run a quick 60-second quantitative test while the device is idle: in the Terminal app, run ethtool -S eth0 | grep rx_packets, note the value, wait 60 seconds, and run it again. If the counter barely changes while the LED still blinks constantly, that confirms the blinking is unrelated to actual traffic and points to the LED driver behavior itself — we will then submit this as formal evidence to our R&D team for in-depth analysis.

Regarding the ethtool statistics, rest assured: CRC and all error counters are zero, so your network environment is healthy.

1. Yes that it almost certainly my cable-switching tests. 2500 Mbps link is the Flint 3 router. 1000 Mbps link is my desktop PC, The 100 Mbps specifically is me plugging it in a JetKVM which I didn't mention previously just to see what happens (no link lights/blinking at all with that strangely but the NIC actually did negotiate the link correctly as evidenced by the dmesg output). Also tried a known good quality cat 6 cable and nothing changed. And I will add that it does the same with BOTH ports LAN1 and LAN2 on the NAS. So it's not the cable and it's not the port.

2. Baseline with GUI:
section94@TNAS:/# ethtool -S eth0 | grep rx_packets
rx_packets: 1873
After ~1 minute with GUI:
section94@TNAS:/# ethtool -S eth0 | grep rx_packets
rx_packets: 2086
After ~5 minutes with GUI:
section94@TNAS:/# ethtool -S eth0 | grep rx_packets
rx_packets: 3088

Baseline with SSH:
section94@TNAS:~# ethtool -S eth0 | grep rx_packets
rx_packets: 5637
After ~1 minute with SSH:
section94@TNAS:~# ethtool -S eth0 | grep rx_packets
rx_packets: 5756
After ~5 minutes with SSH:
section94@TNAS:~# ethtool -S eth0 | grep rx_packets
rx_packets: 5936


Not sure what to make of this. Not sure if that is too much or too little for idle but I feel it would be more if there was real non-stop traffic.

Hello,

Thank you for the data — the physical layer can now be officially ruled out: the speed changes match your cable-switching tests exactly, and with a known-good Cat6 cable plus identical behavior on both LAN ports, the cable and ports are confirmed fine.

As for the quantitative test, the math gives us the answer: at idle you're seeing roughly 3-4 packets per second. The activity LED is driven per-packet, so 3-4 blinks per second appears to the human eye as constant blinking — visually, 3 blinks per second and 30 are nearly indistinguishable. Combined with TOS's own service announcements (your tx count was even higher than rx), this fully explains why the LED appears to blink non-stop while actual traffic is nearly zero.

As for why other devices behave differently: LED behavior is defined by each NIC's driver. Many NICs throttle the LED at low traffic (staying solid until a threshold is reached), while the igc driver here blinks faithfully for every packet — the same trickle simply looks different on different devices.

For a final verification, you can run this in the Terminal app:
The expected output is routine broadcast/multicast chatter from your router and LAN devices (mDNS, SSDP, etc.). If confirmed, we can conclude: the device is completely healthy — this is normal background traffic combined with a per-packet LED policy, with no impact on functionality. We will also submit the LED display behavior difference as product feedback to our R&D team for evaluation.

Thank you for your excellent cooperation throughout!

CursaYang wrote: ↑27 Sep 2026, 21:56 Hello,

Thank you for the data — the physical layer can now be officially ruled out: the speed changes match your cable-switching tests exactly, and with a known-good Cat6 cable plus identical behavior on both LAN ports, the cable and ports are confirmed fine.

As for the quantitative test, the math gives us the answer: at idle you're seeing roughly 3-4 packets per second. The activity LED is driven per-packet, so 3-4 blinks per second appears to the human eye as constant blinking — visually, 3 blinks per second and 30 are nearly indistinguishable. Combined with TOS's own service announcements (your tx count was even higher than rx), this fully explains why the LED appears to blink non-stop while actual traffic is nearly zero.

As for why other devices behave differently: LED behavior is defined by each NIC's driver. Many NICs throttle the LED at low traffic (staying solid until a threshold is reached), while the igc driver here blinks faithfully for every packet — the same trickle simply looks different on different devices.

For a final verification, you can run this in the Terminal app:

Code: Select all

timeout 60 tcpdump -i eth0 -nn 2>/dev/null | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

The expected output is routine broadcast/multicast chatter from your router and LAN devices (mDNS, SSDP, etc.). If confirmed, we can conclude: the device is completely healthy — this is normal background traffic combined with a per-packet LED policy, with no impact on functionality. We will also submit the LED display behaviour difference as product feedback to our R&D team for evaluation.

Thank you for your excellent cooperation throughout!

That command didn't print anything, maybe it doesn't have tcpdump or something is else wrong but I did this command suggested by AI:

GUI:
section94@TNAS:/# while true; do
R1=$(cat /sys/class/net/eth0/statistics/rx_packets)
T1=$(cat /sys/class/net/eth0/statistics/tx_packets)
sleep 1
R2=$(cat /sys/class/net/eth0/statistics/rx_packets)
T2=$(cat /sys/class/net/eth0/statistics/tx_packets)
echo "RX: $((R2-R1)) pkts/sec | TX: $((T2-T1)) pkts/sec"
done
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 4 pkts/sec | TX: 3 pkts/sec
RX: 3 pkts/sec | TX: 3 pkts/sec
RX: 6 pkts/sec | TX: 3 pkts/sec
RX: 18 pkts/sec | TX: 13 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 3 pkts/sec | TX: 3 pkts/sec
RX: 3 pkts/sec | TX: 3 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 6 pkts/sec | TX: 3 pkts/sec
RX: 17 pkts/sec | TX: 13 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 8 pkts/sec | TX: 8 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 3 pkts/sec | TX: 3 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 9 pkts/sec | TX: 3 pkts/sec
RX: 16 pkts/sec | TX: 14 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 5 pkts/sec | TX: 3 pkts/sec
RX: 14 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 5 pkts/sec | TX: 3 pkts/sec
RX: 6 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 9 pkts/sec | TX: 3 pkts/sec
RX: 15 pkts/sec | TX: 13 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 3 pkts/sec | TX: 3 pkts/sec
RX: 3 pkts/sec | TX: 3 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 2 pkts/sec | TX: 2 pkts/sec
RX: 9 pkts/sec | TX: 5 pkts/sec
^C

SSH:
section94@TNAS:~# while true; do
R1=$(cat /sys/class/net/eth0/statistics/rx_packets)
T1=$(cat /sys/class/net/eth0/statistics/tx_packets)
sleep 1
R2=$(cat /sys/class/net/eth0/statistics/rx_packets)
T2=$(cat /sys/class/net/eth0/statistics/tx_packets)
echo "RX: $((R2-R1)) pkts/sec | TX: $((T2-T1)) pkts/sec"
done
RX: 0 pkts/sec | TX: 0 pkts/sec
RX: 2 pkts/sec | TX: 3 pkts/sec
RX: 1 pkts/sec | TX: 1 pkts/sec
RX: 3 pkts/sec | TX: 1 pkts/sec
RX: 2 pkts/sec | TX: 1 pkts/sec
RX: 1 pkts/sec | TX: 0 pkts/sec
RX: 2 pkts/sec | TX: 1 pkts/sec
RX: 3 pkts/sec | TX: 2 pkts/sec
RX: 1 pkts/sec | TX: 0 pkts/sec
RX: 1 pkts/sec | TX: 0 pkts/sec
RX: 1 pkts/sec | TX: 0 pkts/sec
RX: 2 pkts/sec | TX: 1 pkts/sec
RX: 1 pkts/sec | TX: 0 pkts/sec
RX: 2 pkts/sec | TX: 1 pkts/sec
RX: 1 pkts/sec | TX: 0 pkts/sec
RX: 2 pkts/sec | TX: 1 pkts/sec
RX: 1 pkts/sec | TX: 0 pkts/sec
RX: 1 pkts/sec | TX: 0 pkts/sec
RX: 1 pkts/sec | TX: 0 pkts/sec
RX: 2 pkts/sec | TX: 1 pkts/sec
RX: 1 pkts/sec | TX: 0 pkts/sec
RX: 2 pkts/sec | TX: 1 pkts/sec
RX: 1 pkts/sec | TX: 0 pkts/sec
RX: 3 pkts/sec | TX: 0 pkts/sec
RX: 1 pkts/sec | TX: 0 pkts/sec


This captures the traffic from the SSH and GUI sessions definitely and likely along with other occasional broadcast packets. But even when these user sessions are not active as we said the blinking doesn't stop. Couple of final notes:

1) I entered the BIOS just to look around and the LAN led stays off while in there. Maybe the NIC isn't initialized yet. As soon as TOS loads the blinking starts.
2) I am almost certain that when I first got it the LED didn't use behave like that. Maybe a TOS update changed the led driver behaviour to this very sensitive per-packet blinking.