TUF-AX3000 v2 lost all wireless after a couple days on 3004.388.7_1-gnuton0_beta1

[Rovasteen]

I was running 3004.388.7_1-gnuton0_beta1 for a couple days on my TUF-AX3000 v2. While the router was running, I lost 5GHz connection to all my streaming devices. I could not connect to the router on either wireless band from a PC. I power cycled the router and it booted up normally. Did not see anything of interest in the log files.

I reverted back to 3004.388.6_2-gnuton1 which is a build that has performed quite well.

I would like to go to 3004.388.7_1-gnuton0_beta1 as it has a lot of improvements from upstream Merlin (including nice graphics for the Tools menu). There appears to be something in 3004.388.7_1-gnuton0_beta1 that caused the wireless functions to freeze up.

My temps on the radios are 46 degrees C on the 2.4 GHz and 48 degrees C on the 5 GHz. The CPU runs around 59 degrees C most of the time (sometimes a degree or two cooler, and sometimes as much as 60 degrees C).

Not sure if anyone else has experienced this, or if there is something obvious in the commits (I did not see anything obvious) that could have caused this.

Thanks Gnuton for these builds as it makes the TUF-AX3000 v2 a nice performer!

[gnuton]

Hi @Rovasteen thakns for reporting.
Given that both version you tested have same GPL I would not be able to quickly pinpoint what would be the issue for this issue.
The drivers used by both version are the same, which means they should just perform the same.

[Rovasteen]

Could the XT_SET kernel module have caused the router to hang?

[ahulyk]

I could confirm same issue on my TUF-5400 running 3004.388.7_1-gnuton0_beta1

[Rovasteen]

@ahulyk was there anything interesting in your log files that you could share?

[ahulyk]

I did a factory reset. And flashed back latest stable release.

Possible steps to reproduce:
Select manual channel selection (select 100 channel)
Enable 160Mhz
Enable DL/UL + MU MIMO
Enable Multi User Mimo
Security WPA2/WPA3

Disable 2.4 radio

[Rovasteen]

When the router froze up, on the 5Ghz band I was running channel 36 with 160 MHz channel width and WPA2/WPA3.

[ahulyk]

So, could be related to 160Mhz

[Rovasteen]

I don't think that is it. The drivers and GPL are the same between 3004.388.6_2-gnuton (stable) and 3004.388.7_1-gnuton0_beta1 (unstable). The 3004.388.7_1-gnuton0_beta1 has many changes from RMerlin so hard to pinpoint what it may be. I may revert to 3004.388.7_1-gnuton0_beta1 and try to capture in a log file.

[gnuton]

@ahulyk thanks for reporting this.
how long did it take to seee this issue on the TUF-5400?

[Rovasteen]

I am back on 3004.388.7_1-gnuton0_beta1 on the TUF-AX3000 v2. Will try to do a better job collecting data for troubleshooting.

[ahulyk]

@gnuton I reproduced it 2 times. It was caused by pressing Apply button on Professional Wireless tab.

Settinngs (not 100% sure):

Select manual channel selection (select 100 channel)
Enable 160Mhz
Enable DL/UL + MU MIMO
Enable Multi User Mimo
Security WPA2/WPA3

Disable 2.4 radio

[gnuton]

Are you people using the TUF UI or the not TUF UI? Do you see errors in your browser console when applying the changes?

[Rovasteen]

I am using the regular UI. Not sure what is being described as whenever you press the Apply button you will lose connectivity as a normal part of changing wireless parameters.

The defect I reported originally is that you lose contact while the router is running.

[ahulyk]

I was using TUF UI. Is default UI imore stable?

[Rovasteen]

As indicated, any time you have changed a wireless parameter and press Apply, you lose wireless while the parameters are being updated. That is normal. That is not a defect.

I am running the 3004.388.7_1-gnuton0_beta1 build on the TUF-AX3000 v2 and will report back when the defect originally reported happens again.

[gnuton]

@ahulyk no it's not more stable. It's just one of the things TUF-AX3000 v2 and TUF-AX5400 share.
I am trying to guess IF there is a connection between these issues you noticed.

@Rovasteen is correct apply resets the radio if radio params are changed, so connectivity is temporarly lost. This is by design.

Thanks for the collaboration @Rovasteen ! really appreciated.

[Niklasg85]

I cant reproduce the problem, for me its seems to be fine on the latest bets.

[Rovasteen]

@gnuton go ahead and close this issue. I have been running for a number of days with a lot of traffic and cannot replicate the original fault. If the router freezes up again, I will open a new issue + provide the log files for better analysis.