@David-TP 

Hi, I did not restart the Deco.

 

I started watching for whether my phone was on the 2G or 5G signal.  At one point I think it changed to 2G network since I had walked out to the garage so maybe it couldn't hold the 5G but when I came back inside near the Deco it still held the 2G and wouldn't automatically go back to the 5G band.  So I went ahead and turned off 2G on the main SSID so it is only broadcasting 5G.  I turned on Guest network with both 2G and 5G and I'll use that one for devices that need 2G.  This way I can ensure my key devices are always on the main SSID using 5G.

 

Right now I am only testing wireless devices.  I'll work on testing wired today.  When I test wireless to G3100 it is consistently MUCH higher than the Deco.  G3100 wifi is almost 300mb and Deco is between sub100 and 180.  Deco hasn't gotten above the 100's yet from any of the 3 units.

 

On another note, I did notice last night that my 3rd Deco upstairs is returning even lower numbers at 60 to 80 MB.  Is it normal for the speeds to drop that much on the other units?  It also said the signal was Medium, not Strong, when I was only about 7 feet away.  Ugh.  From the same spot, connecting to 5G on G3100 (three floors down so a much weaker signal), the speeds were much much higher.

 

I looked at the log this morning, and there are 67 screens full of error messages in just over 12 hours.  It is throwing these repeatedly (a small snippet):

 

Mon Nov 21 09:55:56 2022 daemon.err nrd[6205]: qca_get_phy_cap_info: get phy cap info failed

Mon Nov 21 09:56:01 2022 daemon.err nrd[6205]: send_mesh_band_steering_ioctl: ioctl failed, cmd: 45

Mon Nov 21 09:56:01 2022 daemon.err nrd[6205]: qca_get_phy_cap_info: get phy cap info failed

Mon Nov 21 09:56:04 2022 authpriv.notice dropbear[12380]: Pubkey auth succeeded for 'root' with key sha1!! 7b:1e:be:46:1b:3e:db:9f:b6:95:12:b3:a1:cb:c3:2e:2d:59:fb:44 from 192.168.71.250:49422

Mon Nov 21 09:56:04 2022 daemon.err udhcpd[11327]: Sending OFFER of 192.168.68.55

Mon Nov 21 09:56:05 2022 daemon.err udhcpd[11327]: Sending ACK to 192.168.68.55

Mon Nov 21 09:56:05 2022 daemon.err udhcpd[11327]: clear ip 3744a8c0

Mon Nov 21 09:56:06 2022 daemon.err nrd[6205]: send_mesh_band_steering_ioctl: ioctl failed, cmd: 45

Mon Nov 21 09:56:06 2022 daemon.err nrd[6205]: qca_get_phy_cap_info: get phy cap info failed

Mon Nov 21 09:56:07 2022 daemon.err bandwidth_contr: get mode: 11AHE160

Mon Nov 21 09:56:11 2022 daemon.err nrd[6205]: send_mesh_band_steering_ioctl: ioctl failed, cmd: 45

Mon Nov 21 09:56:11 2022 daemon.err nrd[6205]: qca_get_phy_cap_info: get phy cap info failed

Mon Nov 21 09:56:15 2022 user.notice IMPROXY: INFO[imp_verify_multicast_addr@245]: Group address 224.0.0.251 is Local Network Control Block

Mon Nov 21 09:56:16 2022 daemon.err nrd[6205]: send_mesh_band_steering_ioctl: ioctl failed, cmd: 45

Mon Nov 21 09:56:16 2022 daemon.err nrd[6205]: qca_get_phy_cap_info: get phy cap info failed

Mon Nov 21 09:56:17 2022 user.notice IMPROXY: INFO[imp_verify_multicast_addr@245]: Group address 224.0.0.251 is Local Network Control Block

Mon Nov 21 09:56:21 2022 daemon.err nrd[6205]: send_mesh_band_steering_ioctl: ioctl failed, cmd: 45

Mon Nov 21 09:56:21 2022 daemon.err nrd[6205]: qca_get_phy_cap_info: get phy cap info failed

Mon Nov 21 09:56:26 2022 daemon.err nrd[6205]: send_mesh_band_steering_ioctl: ioctl failed, cmd: 45

Mon Nov 21 09:56:26 2022 daemon.err nrd[6205]: qca_get_phy_cap_info: get phy cap info failed

Mon Nov 21 09:56:28 2022 user.notice IMPROXY: INFO[imp_verify_multicast_addr@245]: Group address 224.0.0.251 is Local Network Control Block

Mon Nov 21 09:56:28 2022 daemon.err bandwidth_contr: get mode: 11AHE160

Mon Nov 21 09:56:28 2022 daemon.err bandwidth_contr: Sending TIPC data. Total 20 bytes.

Mon Nov 21 09:56:31 2022 daemon.err nrd[6205]: send_mesh_band_steering_ioctl: ioctl failed, cmd: 45

Mon Nov 21 09:56:31 2022 daemon.err nrd[6205]: qca_get_phy_cap_info: get phy cap info failed

Mon Nov 21 09:56:36 2022 daemon.err nrd[6205]: send_mesh_band_steering_ioctl: ioctl failed, cmd: 45

Mon Nov 21 09:56:36 2022 daemon.err nrd[6205]: qca_get_phy_cap_info: get phy cap info failed

Mon Nov 21 09:56:37 2022 daemon.err bandwidth_contr: get mode: 11AHE160

Mon Nov 21 09:56:41 2022 daemon.err nrd[6205]: send_mesh_band_steering_ioctl: ioctl failed, cmd: 45

Mon Nov 21 09:56:41 2022 daemon.err nrd[6205]: qca_get_phy_cap_info: get phy cap info failed

Mon Nov 21 09:56:46 2022 daemon.err nrd[6205]: send_mesh_band_steering_ioctl: ioctl failed, cmd: 45

Mon Nov 21 09:56:46 2022 daemon.err nrd[6205]: qca_get_phy_cap_info: get phy cap info failed

 

If you read all the way to here, I'd be very interested knowing how to see in a list of all devices connected to the network not just wireless.  How can I see what is connected wired thru the ethernet ports?

 

 

  @David-TP 

 

Hi,

 

---when the speed dropped to 20mhz, do you need to restart Deco to get the speed back or it would automatically restore the speed gradually later?

I think it was a case of my phone jumping to 2.4 when I walked into the front yard, and not getting back onto 5ghz when I came back inside.  

I turned of the 2.4 band so I am only using 5ghz and speeds are looking ok.

 

And have you tried to disable 160mhz under the wireless settings and mainly use 80mhz for 5ghz?

--- I have not done this.  I've keep that setting at the default.  Would that affect all the error messages in my system log?  See other reply with more error messages.

 

Moreover, do you have any wired clients and will they drop the speed as well when connected to Deco?

--- I do have wired, but they are things like printers, tv, sonos, not things I'd do a speedtest from.

 

--- If possible, it is also suggested to connect the PC directly to G3100 and check the stability of the internet speed.

I connected my laptop to an ethernet cable and the speeds are fine.  Since turning off the 2.4 on the main SSID, so far so good.  I have the Guest network broadcasting 2.4 and 5 so I can jump on that if I am outside of the house and not getting 5ghz signal, and I use the Guest SSID for my 2.4 devices, like the robot vacuum, and IoT devices.  

 

Big question is what is with all the non-stop error messages in the system log.  Makes me think I just need to return the Deco before I am out of my return period and start feeling the pain of whatever is causing the error messages.

  @AmeliaKD 

 

I am getting the same error with Deco X50s. Mine is a new installation.

 

What's not clear to me is that this is a daemon.err, an error  What has actually caused this error? Should this not be a NOTICE or WARNING?

 

Similarly when a device doesn't support 802.11k, why do we receive a daemon.err. The APs should handle these as notices, since it's not reasonable to expect that end devices will support higher speed and newer protocols. 

Same here: i just installed 3 X50s (using only 2 at the moment) as access points for my wired network with an ISP router.

 

In the log i see many messages saying "daemon.err bandwidth_contr: get mode: 11AHE160"

In another ticket i saw a suggestion to switch to 80MHz for the 5GHz band.

I tried that and that only changed the message to "daemon.err bandwidth_contr: get mode: 11AHE80"

 

 

 

@David-TP

Is anyone looking at these errors ?

There seem to be multiple reports of them and i see no response here.

  @AmeliaKD 

I chatted with tech support and ultimately they said it is a "hardware issue" and the unit needs to be replaced. No real information provided about all the error messages.  I have to return it to TP-link to get a replacement under warranty.  

 

I haven't started the RMA with TP-link because I decided to buy a new unit to see if it has the same issues (and I'd just return the other one since I am in my return window).  Sure enough, a new set of 3-unit started throwing similar errors right away.  Within 12 hours of being up, I had 76 pages full of errors. 

 

So it would appear that this is a common problem with these units.  Very disappointing.