@AlphaBetaGamma 

There is another test you can do to definitely prove if it is or it is not the Ethernet cable. 

Take problematic Satellite M4 that shows WiFi backhaul to where your Main or another Satellite M4 is. Connect that problematic Satellite M4 to the second port of Main M4 or another Satellite M4, using different and short Ethernet cable. You now have two Decos daisy chained to each other: problematic one to "good" one.

If with this setup problematic Satellite M4 still shows WiFi backhaul, while connected by different and short Ethernet cable to "good" M4, then something must be wrong with problematic M4.

@AlphaBetaGamma  thanks for the tip.  I did as you suggest and the problematic M4 is still showing the signal source as 'wifi' although it is directly connected with a known good ethernet cable to the main M4.  I'll try to take it up with TP-Link.

I did call the support chat line at TP-Link.  They advised doing a hard reset on the satellite M4, but this did not help.  I have 6 Decos, the main and 2 satellites connected with etheret, and the other three over wifi.  I have noticed that all three ethernet connected Decos have a low IP address (192.168.0.13, .14, and .16 ) and the wifi ones have a high one (.145, .147, .148), so even though the ethernet satellites show their signal source on the Deco app to be wifi, the addresses suggest to me that they are working with the eternet backhaul and it is the app that is incorrectly reporting the signal source (Deco app firmware 1.4.3).

@AlphaBetaGamma 

If you are OK with your mesh performance, you can just leave this issue and revisit it after next firmware upgrade. 

If you would like to poke a bit more, these are log lines you can check on problematic Deco M4 to see if it is indeed using Ethernet backhaul. 

Log lines to look for, for two options: bounce problematic M4 and pull cable from running M4.

Important: you need logs from problematic Satellite Deco, not from Main Deco. You can get Satellite Deco logs by using its IP address in a browser. Use default NOTICE log type when scanning or downloading logs to local drive. 

1. Bounce problematic M4.

After M4 restarts and connected to mesh, check if you see this log line in its logs:

daemon.notice awn[1214]: [awnd_eth_handle_neigh:3941]: Activaing Ethernet backhaul in eth1, disconnect other backhuals.

Note that you might see eth0 instead of eth1 in that log line.

followed after some time by:

daemon.notice awn[1214]: [awnd_eth_handle_neigh:3961]: Ethernet backhaul is active now.

2. Pull Ethernet cable from running M4.

Assuming your problematic M4 uses Ethernet backhaul, pull Ethernet cable off it. Its LED will go red briefly. Wait till M4 stabilizes by establishing WiFi backhaul, give few more minutes, connect Ethernet cable back.

2.1 These are log lines you should expect to see after pulling cable off:

daemon.notice conn-indicator: Connectivity changed: ONLINE(0x0) -> FAP.LOST(0x4)

...

daemon.notice awn[1235]: [awnd_conn_inspect_status:2388]: WIFI backhaul is connected.

2.2 These you should expect to see after connecting Ethernet cable back:

daemon.notice netifd: Network device 'eth0' link is up

...

daemon.notice awn[1235]: [awnd_eth_handle_neigh:3983]: Activaing Ethernet backhaul in eth0, disconnect other backhuals.

...

daemon.notice awn[1235]: [awnd_eth_handle_neigh:4003]: Ethernet backhaul is active now.

Note that depending on Deco port used to connect Ethernet cable to, you might see eth1 instead of eth0 in these log lines.