@Solla-topee 

Hello,

OK for me 1.3.0 Build 26071612 Rel. 73941 --> 1.3.0 Build 26080612 Rel. 48751 

Same problem with the 2 firmwares : "Operation failed" when Clear All logs.

  @Solla-topee 

Are there any plans to support configuring hostnames since the default name used by all BE85 devices is a serious annoyance when my dhcp server assigns IP addresses and name collisions result at rhe dns server level.

  @Solla-topee 

Hello,

Yes except kern.emerg

Clear logs at 06:46

Tested : Chrome and FireFox

Wed Aug 26 22:21:20 2026 kern.emerg : PRIVACY_ASSETS_CLCT_ONLINE_STAT_INFO

Wed Aug 26 22:21:20 2026 kern.emerg : PRIVACY_ASSETS_CLOUD_REPORT_SUCCESS

Wed Aug 26 22:31:20 2026 kern.emerg : PRIVACY_ASSETS_CLCT_ONLINE_STAT_INFO

Wed Aug 26 22:31:20 2026 kern.emerg : PRIVACY_ASSETS_CLOUD_REPORT_SUCCESS

Wed Aug 26 22:41:20 2026 kern.emerg : PRIVACY_ASSETS_CLCT_ONLINE_STAT_INFO

Wed Aug 26 22:41:20 2026 kern.emerg : PRIVACY_ASSETS_CLOUD_REPORT_SUCCESS

Wed Aug 26 22:51:20 2026 kern.emerg : PRIVACY_ASSETS_CLCT_ONLINE_STAT_INFO

Wed Aug 26 22:51:20 2026 kern.emerg : PRIVACY_ASSETS_CLOUD_REPORT_SUCCESS

Thu Aug 27 06:46:21 2026 daemon.err nrd[3478]: send ioctl failed

Thu Aug 27 06:46:22 2026 daemon.err nrd[3478]: send ioctl failed

Thu Aug 27 06:46:23 2026 daemon.err ai-center: [eth_get_linkrate:103]: Unknown Duplex! (255)

Thu Aug 27 06:46:23 2026 daemon.err ai-center: [eth_get_linkrate:103]: Unknown Duplex! (255)

Thu Aug 27 06:46:23 2026 daemon.err nrd[3478]: send ioctl failed

  @Solla-topee 

 

Hardware: Deco BE85 (2-pack), V1, Main unit + Satellite in AP mode
Firmware path: v1.2.4 → v1.3.0 (pre-release), as instructed in this thread
Backhaul: Currently Ethernet wired backhaul between the two units 2.5G port (planning to move to wired 10G backhaul)

Hi everyone,

After completing the guided upgrade from 1.2.4 to the 1.3.0 pre-release, I've been reviewing the syslog output and noticed a new error that was NOT present in my logs before the update.

The message:
 

daemon.err ai-center: eth_get_linkrate:103: Unknown Duplex! (255)

This error is logged repeatedly and continuously, roughly every 5 seconds, and keeps appearing for hours after boot — it is not limited to the initial post-upgrade reconfiguration window. I confirmed this by comparing:

• A log captured on 1.2.4 (before the upgrade): zero occurrences of this string, and no "ai-center" errors related to link rate/duplex detection at all.
• Two separate logs captured on 1.3.0, taken about 2.5 hours apart on the same day: the error is present in both, at the same steady frequency, well after the system had fully settled (no other boot-related noise, no interface reinitialization messages, no client disconnect storms).

So this appears to be a new behavior introduced specifically by 1.3.0, not a pre-existing hardware/cabling issue, since it never occurred on the previous firmware with the exact same physical setup.

Other observations from the same logs, for context:

• Wi-Fi clients associate/re-associate normally and complete the WPA 4-way handshake without issues.
• "Notify inet.up" keeps appearing regularly, so this does not seem to affect actual internet connectivity.
• I did also see a separate, apparently temporary set of issues limited to the first few minutes after the upgrade (improxy crash loop due to br-wan missing an IPv6 address, an nrd restart with "No WLAN interface listed in config file", and some eth2 link flapping) — but none of those persisted; only the "Unknown Duplex! (255)" message is a steady, ongoing condition.

Questions for TP-Link / other testers:

1. Is "ai-center" a new module introduced in 1.3.0?
2. What is it responsible for (I'm guessing some new AI-based network/QoS monitoring tied to the Internet Backup or Hybrid Mesh features)?
3. Is this duplex read failure purely cosmetic/logging noise, or could it affect any duplex-dependent feature (e.g. speed/QoS decisions, path selection for wired backhaul)?
4. I'm about to move my backhaul cable to the 10G ports between the two BE85 units — should I be concerned this error could interfere with correct link speed/duplex negotiation on those ports, or is it unrelated to actual port negotiation?

Happy to share the full syslog snippets or run further tests if that helps triage this.

Thanks!

  @Solla-topee 

Hardware: Deco BE85 V1 (2-pack), Main unit + Satellite in AP mode
Firmware: v1.3.0 pre-release
Cabling: Certified Cat7 Ethernet cable throughout all tests below (same cable, only the ports it was plugged into were changed)

 

Following up on my earlier post about the recurring "ai-center: eth_get_linkrate: Unknown Duplex! (255)" error, I ran a series of controlled tests moving the wired backhaul between different ports. Posting the full picture because I now have a reproducible real-world failure, not just a log oddity.

TEST 1 — Backhaul on the 10G combo (RJ45/SFP+) port

Result: Fans on both units ramp up to maximum speed, seemingly unrelated to actual network load. This matches other users' reports in this community about fan behavior on the combo port, but in my case it happens even without any SFP+ transceiver installed — plain RJ45 Cat7 cable only.
 

TEST 2 — Backhaul on the second, non-combo 10G port

Result: Complete backhaul failure.
 

• After rebooting both units with the backhaul cable (same certified Cat7 cable) on this port, the satellite unit's LED stayed solid green (implying "all OK"), but:
• The Deco app showed the Main unit online, while the Satellite didn't even show as "offline" — it was simply absent from the topology, as if the mesh controller had no knowledge of it.
• A MacBook Pro wired directly to the Satellite had no internet access at all.
• Wi-Fi clients connected to the Satellite also had no internet access, despite showing a normal Wi-Fi connection.
• Syslog captured right after this reboot showed:
• fan[xxxx]: uci get fan_dev_path failed! / uci get fan_num failed! / No HWVER, fan control individually / fan zero — the fan control daemon failed to load its configuration entirely.
• device eth2 is already a member of a bridge, can't enslave it to bridge br-lan — a direct bridge configuration conflict on one of the 10G-mapped interfaces.
• netifd: Network device eth3 link is up / down, repeated several times — the second 10G port flapping.
• ai-center: ac_tipc_send:193: Fail to send TIPC data. Host is unreachable — the ai-center module failing to reach the peer unit over the internal TIPC channel, right when the Satellite was invisible to the mesh.
• The usual "Unknown Duplex! (255)" errors were present from the very first seconds after boot.
• A large repeated block of "procd: etc/rc.d/S99nrd: sh: out of range" (50+ consecutive identical lines) during nrd startup — not seen in previous boots on 1.2.4 or in earlier 1.3.0 sessions using lower-speed ports.
   

TEST 3 — Isolating the variable: 10G combo port used as a LAN client port, not backhaul

• I have used the 10G combo port on both units for a wired client (MacBook Pro) for extended periods, completely independently of backhaul configuration, and have never observed the fan spin-up issue in that role.
• This strongly suggests the fan/stability issue is NOT tied to the 10G port hardware or to the combo/SFP+ port design itself, but specifically to the backhaul path-selection logic when a 10G port is assigned that role. The same physical port, used only as a LAN uplink for a device, behaves normally.
   

CURRENT STABLE WORKAROUND

• Main unit: WAN from modem on the 10G combo port; wired backhaul to Satellite out via the Main's non-combo 10G port.
• Satellite unit: wired backhaul in via its 2.5G port (not 10G); MacBook Pro wired client on the Satellite's 10G combo port.
• Same certified Cat7 cable used for the backhaul link throughout all tests — cabling has been ruled out as a variable.
• With this asymmetric setup (10G on one backhaul end, 2.5G on the other), the link negotiates down to 2.5 Gbps, but both units are stable again, the Satellite is visible in the app, internet works normally, and fans have returned to normal/silent behavior so far.

WORKING HYPOTHESIS

• The "ai-center" module (new/changed in 1.3.0, responsible for the recurring Unknown Duplex error) appears to be involved in wired backhaul path-selection and/or fan control decisions. When both ends of the backhaul are on ports mapped as "10G" (eth_10G_name[0]/eth_10G_name[1] per the apsd path-selection log), something in that negotiation breaks: the bridge configuration fails, the link flaps, the fan control config fails to load, and the mesh loses track of the Satellite entirely.
• Using a 2.5G port on either end of the backhaul avoids the issue, and using a 10G port purely as a LAN uplink (not backhaul) also avoids it.
   

Questions for TP-Link:
 

1. Can you confirm whether "ai-center" governs both fan control and wired backhaul path-selection between 10G-capable ports?

2. Is there a known issue in 1.3.0 with backhaul negotiation when both link ends are seen as "10G-class" interfaces (eth2/eth3 in the apsd path-selection log)?

3. Is downgrading to 1.2.4 recommended until this is fixed, or is a hotfix expected soon given this causes a full mesh/connectivity outage, not just log noise?

Happy to share full syslog captures for all three tests (before/after each port change) if that helps engineering triage this faster.

  @Solla-topee 

UPDATE — Satellite fault on the currently stable 10G-to-2.5G wired-backhaul configuration
 

I have an additional real-world failure to report after reverting to the configuration that had appeared stable:
 

- Main Deco BE85:
  - modem/uplink connected to the 10G combo port;
  - wired backhaul leaving from the second, non-combo 10G port.

- Satellite Deco BE85:
  - wired backhaul connected to a 2.5G port;
  - MacBook Pro connected as a wired client to the 10G combo port.
 

The backhaul cable is the same certified Cat7 cable used in all tests.
 

At approximately 18:02 on August 31, the Satellite unit (LAN MAC XX-XX-XX-XX-X6-EC / IP 192.168.1.14) entered a fault state:
- Its LED turned red.
- The satellite became unreachable.
- It disappeared completely from the Deco app topology; it was not even displayed as “offline”.
- A manual reboot of the Satellite was required to recover it.
 

Relevant log sequence from the Main unit:

18:02:04
nrd_tipc_send: Notification : failed to send, err(-1)
 

18:02:06
netifd: Network device 'eth2' link is up
conn-indicator: link event: eth2.up
 

18:02:07
tipc-tfstats: Send TIPC notification failed: Host is unreachable
 

18:02:10
/usr/bin/apsd: uci_get_value: Error: fail to get ptr aggregation_network
 

18:02:17
tss: handle probe info get key:new_offline_devId
tss: event: going to add device!
 

18:02:22
TPAP/NOC authentication to 192.168.1.14:30001 completed successfully
(error_code:0)
 

18:02:24
client_mgmt: client(XX-XX-XX-XX-X6-EC) disconnected

This shows that the issue is not limited to 10G-to-10G backhaul. Even with the asymmetric 10G-to-2.5G wired backhaul, the mesh control channel briefly loses reachability to the Satellite. The Main unit detects the peer as offline, TIPC reports “Host is unreachable”, and the Satellite is subsequently marked as disconnected.

One important clarification: the successful TPAP/NOC authentication at 18:02:22 means the Satellite was still intermittently reachable shortly before it was marked disconnected at 18:02:24. Therefore, I cannot conclude that TIPC itself is the root cause; it may be reporting the failure after a lower-level Ethernet, bridge, path-selection, or service-state problem occurs.
 

The recurring error below continues before, during, and after this incident:

ai-center: eth_get_linkrate: Unknown Duplex! (255)

Since this error also occurs when the network is otherwise working, I am not claiming it directly caused this failure.

However, it is a persistent 1.3.0 issue and may be relevant to Ethernet link/path monitoring.
 

Could TP-Link please advise:
1. Which service or interface owns eth2 in this AP-mode wired-backhaul topology?
2. Why would eth2 generate a new “link is up” event immediately before the TIPC “Host is unreachable” failure?
3. Is there a known issue in firmware 1.3.0 involving TIPC/TPAP mesh communication, aggregation_network, or path-selection in AP mode with wired Ethernet backhaul?
4. Can engineering provide a debug build, diagnostic commands, or an official method to capture logs from both units before a manual reboot?

I can provide the complete syslog from the Main unit and repeat controlled tests if needed.