Menu
What's new
By:
Filters Better Search

In some dire need of assistance (AX86U)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

KevTech said:
Default is now disabled at least on the ax86.
Click to expand...

I made it disabled by default long ago on my firmware, and had a few discussions with Asus on also making it so on the stock firmware. They may have also eventually made the same change.
 
RMerlin said:
I made it disabled by default long ago on my firmware, and had a few discussions with Asus on also making it so on the stock firmware. They may have also eventually made the same change.
Click to expand...

I was referring to stock and it is default disabled on the ax86.
 
KevTech said:
I was referring to stock and it is default disabled on the ax86.
Click to expand...

Means they went down the same road as me, because initially it was enabled by default.
 
Unfortunate news. All the googles broke at some point today. Logs indicate around 7-8pm. I have saved the log and will upload to pastebin... @ColinTaylor: Would you be willing to review... Perhaps even @RMerlin ?

Thanks.
 
cooloutac said:
are they disconnecting from router, or just not getting internet? How did you set up the pi-hole? All I do in the router is add the pi hole address to the dhcp dns entry in lan settings. I don't put a domain name or anything else. in the wan section of router I just put any public dns.
Click to expand...
They Disconnect from the router it seems - and think they cannot get an address.
 
couldn't paste the crash (10k limit)
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 wl1: PSM microcode watchdog fired at 432335 (seconds). Resetting.
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 wl1: reason = psm watchdog at 432335 seconds. corerev 129.1 ucode revision 1570.159 features 0x9106
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 psmdebug 0x01ff000d phydebug 0x1 macctl 0x4160403 maccmd 0x4
Dec 12 19:42:15 kernel: CONSOLE: psm_brc 0xa400 psm_brc_1 0x000c M_UCODE_DBGST 0x2
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 PSMR1: psmdebug 0x0000009b macctl 0x4060402 maccmd 0x0 M_UCODE_DBGST 0x2
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 brwk_0 0x0501 brwk_1 0x0010 brwk_2 0x82a0 brwk_3 0x0ff0 brwk_4 0x0006
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 ifsstat 0x9da0 ifsstat1 0x1f0 txectl 0x481d txestat 0x445
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 rxestat1 0x1 rxestat2 0x500 rcv_frmcnt 0x0 rxe_rxcnt 0x68
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 wepctl 0x0
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 aqmf_ready0 0x0 aqmf_ready1 0x0 aqmf_ready2 0x0 aqmf_ready3 0x0
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 aqmf_ready4 0x12 wepstat 0x0 wep_ivloc 0x1a wep_psdulen 0x62
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 rxe_errval 0x0 rxe_errmask 0x20f rxe_status3 0x108 txe_status2 0x445
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 dbg_bmc_status 0x0 psm_chk0_err 0x0 psm_chk1_err 0x0
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 PC :
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R0: 0x24 0x24 0x24 0x24
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 R1: 0x9b 0x9b 0x9b 0x9b
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 phydebug :
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x1 0x1 0x1 0x1
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x1 0x1 0x1 0x1
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x1 0x1 0x1 0x1
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x1 0x1 0x1 0x1
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x1 0x1 0x1 0x1
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x1 0x1 0x1 0x1
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x1 0x1 0x1 0x1
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x1 0x1 0x1 0x1
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 pktproc 0x101 pktproc 0x101 pktproc 0x101 pktproc 0x101
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 TxFifoStatus0 0x1c3 TxFifoStatus1 0x1c3
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 gpiosel 0x0 gpiolo 0x0 gpiohi 0x0
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 gpiosel 0x1 gpiolo 0x0 gpiohi 0x0
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 psm stack_status : 0x8000
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 psm stack_entries:
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x0024
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x1c5c
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x1abb
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x1a9a
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x086c
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x0848
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x0848
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0x086a
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 0) usr_count = 0, schedid = 0
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 1) usr_count = 0, schedid = 0
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 2) usr_count = 0, schedid = 0
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 3) usr_count = 0, schedid = 0
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 wl1: wlc_check_assert_type HAMMERING: reinit_reason 2
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 wl1: fatal error, reinitializing
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 wl1: fatal error, reinitializing, total count of reinit's[15]
Dec 12 19:42:15 kernel: CONSOLE: 487454.928 wl1: 802.11 reinit reason[2], count[15]
Dec 12 19:42:16 kernel: CONSOLE: 487455.013 wl1: wlc_bmac_suspend_mac_and_wait: waited 83000 uS and MI_MACSSPNDD is still not on.
Dec 12 19:42:16 kernel: CONSOLE: 487455.013 wl1: reason = mac suspend failure at 432335 seconds. corerev 129.1 ucode revision 1570.159 features 0x9106
Dec 12 19:42:16 kernel: CONSOLE: 487455.013 psmdebug 0x01ff000d phydebug 0xb macctl 0x4160402 maccmd 0x4
Dec 12 19:42:16 kernel: CONSOLE: psm_brc 0xa400 psm_brc_1 0x000c M_UCODE_DBGST 0x2
Dec 12 19:42:16 kernel: CONSOLE: 487455.013 PSMR1: psmdebug 0x0000009b macctl 0x4060402 maccmd 0x0 M_UCODE_DBGST 0x2
Dec 12 19:42:16 kernel: CONSOLE: 487455.013 brwk_0 0x0581 brwk_1 0x0095 brwk_2 0xaaa0 brwk_3 0x0ef0 brwk_4 0x0006
Dec 12 19:42:16 kernel: CONSOLE: 487455.013 wlc_dump_ucode_fatal: log_done 0x2
Dec 12 19:42:16 kernel: CONSOLE: 487455.013 HWA4a TxSTAT: hwa_txstat_reclaim: reinit<1> stall<0>
Dec 12 19:42:16 kernel: CONSOLE: 487455.013 HWA3b TxFIFO: reclaim fifo 1 pkts 1
Dec 12 19:42:16 kernel: CONSOLE: 487455.013 HWA3b TxFIFO: reclaim fifo 4 pkts 4
Dec 12 19:42:16 kernel: CONSOLE: 487455.013 HWA1b RxFILL: mac_counter_status sat<0> need_post<0> aval<256>
Dec 12 19:42:16 kernel: CONSOLE: 487455.013 HWA1b RxFILL: reclaim core<0> 256 rxbuffers RD<132> WR<388>
Dec 12 19:42:16 kernel: CONSOLE: 487455.013 HWA1a RxPOST: wi_cnt<128> in hwa internal memory<RD:56 WR:56>
Dec 12 19:42:16 kernel: CONSOLE: 487455.014 wl1: wlc_bmac_wowlucode_start mctrl=0x4020402 0x4000400
Dec 12 19:42:16 kernel: CONSOLE: 487455.014 wl1: wlc_bmac_wowlucode_start (mctrl | MCTL_PSM_JMP_0)=0x4020406 0x4020406
Dec 12 19:42:16 kernel: CONSOLE: 487455.014 wl1: wlc_bmac_wowlucode_start mctrl=0x4020402 0x4020402
Dec 12 19:42:16 kernel: CONSOLE: 487455.016 wl1: CORE INIT : mode 4 pktclassify 1 rxsplit 1 hdr conversion 1 DMA_CT Enabled
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for a0:d0:dc:4c:43:2c seq 0x3ab tid 0
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for a0:d0:dc:4c:43:2c seq 0x1d4 tid 1
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for a0:d0:dc:4c:43:2c seq 0x1 tid 5
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for 32:12:86:2c:af:ec seq 0x69f tid 0
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for 32:12:86:2c:af:ec seq 0xa8a tid 1
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for 32:12:86:2c:af:ec seq 0x1 tid 5
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for 32:12:86:2c:af:ec seq 0x1 tid 6
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for c2:0b:77:9c:5a:97 seq 0xe2e tid 0
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for c2:0b:77:9c:5a:97 seq 0x77e tid 1
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for c2:0b:77:9c:5a:97 seq 0x1 tid 5
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for c2:0b:77:9c:5a:97 seq 0x3 tid 6
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for 4c:17:44:9f:22:cd seq 0xa4f tid 0
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for 4c:17:44:9f:22:cd seq 0x804 tid 1
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for 4c:17:44:9f:22:cd seq 0x1 tid 5
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wl1.0: wlc_send_bar: for 4c:17:44:9f:22:cd seq 0x4 tid 6
Dec 12 19:42:16 kernel: CONSOLE: 487455.033 wlc_mutx_active_update vasip mu_supported_Ntx 4
Dec 12 19:42:16 kernel: CONSOLE: 487455.034 HWA1a RxPOST: H2D RxPost ring: id<1> type<0> item_type<1> max_items<1024> len_item<8>
Dec 12 19:42:16 kernel: CONSOLE: 487455.034 HWA1a RxPOST: item_size 8 CWI32 config parser<00000000> format<0> size<8>
Dec 12 19:42:16 kernel: CONSOLE: 487455.034 HWA1a RxPOST: rxpost_data_buf_len<1836>
Dec 12 19:42:16 kernel: CONSOLE: 487455.037 MQ: wlc_tx_fifo_sync_complete: TXPENDTOT = 7
Dec 12 19:42:16 kernel: CONSOLE: 487455.037 MQ: wlc_tx_fifo_sync_complete: fifo 0: collected 1 pkts
Dec 12 19:42:16 kernel: CONSOLE: 487455.037 MQ: wlc_tx_fifo_sync_complete: fifo 1: collected 1 pkts
Dec 12 19:42:16 kernel: CONSOLE: 487455.037 MQ: wlc_tx_fifo_sync_complete: fifo 2: collected 1 pkts
Dec 12 19:42:16 kernel: CONSOLE: 487455.037 MQ: wlc_tx_fifo_sync_complete: fifo 12: collected 1 pkts
Dec 12 19:42:16 kernel: CONSOLE: 487455.037 MQ: wlc_tx_fifo_sync_complete: fifo 13: collected 1 pkts
Dec 12 19:42:16 kernel: CONSOLE: 487455.037 MQ: wlc_tx_fifo_sync_complete: fifo 15: collected 1 pkts
Dec 12 19:42:16 kernel: CONSOLE: 487455.037 MQ: wlc_tx_fifo_sync_complete: fifo 17: collected 1 pkts
Dec 12 19:42:16 kernel: CONSOLE: 487455.037 CSIMON: already initialized ...
 
Upload the log in Pastebin or another similar sharing site. Provide the link here for review.
 
shadowfiber said:
They Disconnect from the router it seems - and think they cannot get an address.
Click to expand...
This seems to be the core problem. The clients are being disassociated for some reason, after which they appear to reconnect successfully but only have partial network connectivity (it looks like they can talk to the LAN but aren't receiving the replies).

This looks like a low level bug/incompatibility in the wireless code to me. There doesn't appear to be anything that the user can do so I think this will have to be solved by Asus or Google. You could try changing the 2.4GHz "Wireless Mode" to "N only" and seeing if that makes a difference.

Here is the relevant sequence of events for one client:
Code: 
Dec 12 20:19:34 kernel: wl0: random key value: D91733EA9FA3CD7E2AD0017ABCE6625E6F2F03B9C3B90F7634D3CEAD15B68C63
Dec 12 20:19:34 hostapd: eth6: STA 48:d6:d5:65:d4:d0 IEEE 802.11: disassociated
Dec 12 20:19:34 wlceventd: wlceventd_proc_event(469): eth6: Deauth_ind 48:D6:D5:65:D4:D0, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)

Dec 12 20:19:38 wlceventd: wlceventd_proc_event(505): eth6: Auth 48:D6:D5:65:D4:D0, status: Successful (0)
Dec 12 20:19:38 hostapd: eth6: STA 48:d6:d5:65:d4:d0 IEEE 802.11: associated
Dec 12 20:19:38 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Dec 12 20:19:38 wlceventd: wlceventd_proc_event(534): eth6: Assoc 48:D6:D5:65:D4:D0, status: Successful (0)
Dec 12 20:19:38 hostapd: eth6: STA 48:d6:d5:65:d4:d0 RADIUS: starting accounting session 4AF434562516561D
Dec 12 20:19:38 hostapd: eth6: STA 48:d6:d5:65:d4:d0 WPA: pairwise key handshake completed (RSN)

Dec 12 20:19:39 dnsmasq-dhcp[6114]: DHCPREQUEST(br0) 192.168.1.141 48:d6:d5:65:d4:d0
Dec 12 20:19:39 dnsmasq-dhcp[6114]: DHCPACK(br0) 192.168.1.141 48:d6:d5:65:d4:d0 GHM-Masterbed

Dec 12 20:19:42 dnsmasq-dhcp[6114]: DHCPREQUEST(br0) 192.168.1.141 48:d6:d5:65:d4:d0
Dec 12 20:19:42 dnsmasq-dhcp[6114]: DHCPACK(br0) 192.168.1.141 48:d6:d5:65:d4:d0 GHM-Masterbed

Dec 12 20:19:44 dnsmasq-dhcp[6114]: DHCPDISCOVER(br0) 48:d6:d5:65:d4:d0
Dec 12 20:19:44 dnsmasq-dhcp[6114]: DHCPOFFER(br0) 192.168.1.141 48:d6:d5:65:d4:d0

Dec 12 20:19:47 dnsmasq-dhcp[6114]: DHCPDISCOVER(br0) 48:d6:d5:65:d4:d0
Dec 12 20:19:47 dnsmasq-dhcp[6114]: DHCPOFFER(br0) 192.168.1.141 48:d6:d5:65:d4:d0

Dec 12 20:19:56 dnsmasq-dhcp[6114]: DHCPDISCOVER(br0) 48:d6:d5:65:d4:d0
Dec 12 20:19:56 dnsmasq-dhcp[6114]: DHCPOFFER(br0) 192.168.1.141 48:d6:d5:65:d4:d0
 
Hey Colin, Thanks for reviewing. I did try the mode to N only - it did not change the outcome.

I have submitted the information to Asus - and have been trying to work with them for the past month or two - but no outcome just yet.
 
Unfortunately, it seems on Beta2 of merlin firmware, they're really unhappy - Google's disconnect every day, if not a couple times - not sure if that helps anyone @RMerlin

No response from ASUS other than they're looking into it.
 
shadowfiber said:
Unfortunately, it seems on Beta2 of merlin firmware, they're really unhappy - Google's disconnect every day, if not a couple times - not sure if that helps anyone @RMerlin

No response from ASUS other than they're looking into it.
Click to expand...

Anything related to wifi is closed source, so that part of my firmware will always behave the same as the stock firmware version on which mine is based off.
 
RMerlin said:
Anything related to wifi is closed source, so that part of my firmware will always behave the same as the stock firmware version on which mine is based off.
Click to expand...
Thanks so much for clarifying this for me; provides more ammo to ASUS to get them to look at it..
 
Wireless drivers were updated in 386.

3.0.0.4.384.9318
Broadcom BCA: 17.10 RC121.11
wl0: Oct 21 2020 14:23:41 version 17.10.121.11 (r783116)

9.0.0.4.386.41157
Broadcom BCA: 17.10 RC121.37
wl0: Nov 30 2020 11:15:42 version 17.10.121.37 (r789389)
 
I'm about to do a similar upgrade: currently on an AC-66U B1 with asuswrt-merlin for around 3 (happy) years. I have a new AX-86U in shrink-wrapped box and hoping to find time to switch during the coming holiday, out of work hours. What's holding me off is it may take me several hours to do the switch.

Question to OP: did you change the naming of wireless SSID from the previous router to the new router, or did you use the same SSID name?

I've read somewhere on this forum that clients may store information of router wireless hardware with the SSID when first used, which may cause issues re-using the same SSID same switching to a new router wireless hardware such as AX. My plan for the switch to AX-86U radio is to create a new SSID name which means setting the new router AND all the many devices as well, hence why this should take me several hours.
 
@Chuckles67 Thanks for the reply, we did keep the same SSID's, as it's been a pretty norm practice from what I know; that being said though, please let us know if you have the same issue after changing SSID's. It's definitely an undertaking depending on environment!

Thanks!
 
@Chuckles67 these links may be helpful. You don't have to use a new SSID (you can also 'forget' and reset all client devices networks too), but simply using a new SSID is easier, and faster.

www.snbforums.com

ASUS RT-AX88U Range Improvements...

Evening. Recently replaced my Nighthawk R7000 with the RT-AX88U due to the R7000 starting to give up with weekly reboots. Set the AX88U up and am currently running the stock updated firmware and have all my devices connected with static IP's and the network is now running smooth with no need...
www.snbforums.com www.snbforums.com

New M&M 2020
 
Did you change the routers ip-range explicitly? My ax86u defaults to 192.168.50.x.. and it caused some issues for some devices who expected .1.x. But since your devices works a for a while with the router(right?) that obviously isn’t the problem.. it just got me curious.
 
kabukimurder said:
Did you change the routers ip-range explicitly? My ax86u defaults to 192.168.50.x.. and it caused some issues for some devices who expected .1.x. But since your devices works a for a while with the router(right?) that obviously isn’t the problem.. it just got me curious.
Click to expand...

Yes, been on a 192.168.1.0/24 network from the older device and moved that over.
 
On the new AX86U with new SSID and not seeing any specific disconnections.
Google devices on the network include a Google Pixel 4 smartphone and a Google Pixelbook (but no Google smart speakers like Mini or Home): wifi connections seem stable.
 
Has anyone had any success since the last post? This has been driving me crazy.

Tried:
- Disable Smart Connect
- Disable 802.11ax/Wi-Fi 6 mode
- Disable Target Wake Time
- Disable Airtime Fairness
- Disable Roaming Assistant
- Set Preamble Type to Long
- Set Modulation Scheme to MCS 9
- Disable Multi-User MIMO
- Disable Explicit Beamforming
- Disable Universal Beamforming

Logs show the MAC address of the Google devices disconnecting as well.:

Line 4757: Jan 6 23:39:11 wlceventd: wlceventd_proc_event(464): eth6: Deauth_ind <my mac address>, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)

Google searches show Asus routers have this problem for the past ~2 years, and it is not unique to the AX86U. Do we just give up using Google IoT devices?
 
You must log in or register to reply here.

Similar threads

thegios
Google camera troubleshooting
2
Replies
20
Views
2K
sfx2000
sfx2000
J
XT12 / Dual WAN / nextdns / IOT
Replies
8
Views
948
j0ffrey
J
S
Late to the Squarespace domain cutover, need a new DDNS solution...
Replies
9
Views
1K
EPR
E
G
DHCP range not accepted
Replies
4
Views
199
bbunge
bbunge
I
[RT-AX86U Pro] Constant blips during video calls
Replies
8
Views
614
iyoti
I
Similar threads
Thread starter Title Forum Replies Date
L Need help with bwdpi command ASUS AX Routers & Adapters (Wi-Fi 6/6e) 0
M Desperate need for help, packet loss on Asus ax11000, no solution. ASUS AX Routers & Adapters (Wi-Fi 6/6e) 10
M ASUS XT8 w/ 2.5G multigig switch +XT8 nodes not working (need help) ASUS AX Routers & Adapters (Wi-Fi 6/6e) 3
O Need help designing & building AIMESH system ASUS AX Routers & Adapters (Wi-Fi 6/6e) 11
S Late to the Squarespace domain cutover, need a new DDNS solution... ASUS AX Routers & Adapters (Wi-Fi 6/6e) 9
B Need some help ax88U ASUS AX Routers & Adapters (Wi-Fi 6/6e) 10
S Asus DSL-AX82U problems need tech help please ASUS AX Routers & Adapters (Wi-Fi 6/6e) 24
N Fios, AXE11000 2 pack, TP link switch, and do I need vlan iptv? ASUS AX Routers & Adapters (Wi-Fi 6/6e) 8
S Need advice - Asus AIMesh with node serving as ethernet switch vs Asus router and unmanaged ethernet switch ASUS AX Routers & Adapters (Wi-Fi 6/6e) 2
M Need help getting RT-AX86U set up. ASUS AX Routers & Adapters (Wi-Fi 6/6e) 19

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Total: 657 (members: 27, guests: 630)
Top