WAX202 22.03.3 2g wireless disabled yet pops on

2 days in a row, I've noticed that the LED on the 2g wireless IF comes on between the hours of 3 AM and 8 AM.

Need a suggestion on shell commands or logs one would like to see when/if this pops up again.

Do you have a wifi scheduler?

Ironically, I was following that thread yesterday, At the time of reading NO.

Is the issue related to the LED only, or is the radio turning on whne you expect it to be off?

Also, when you say:

Does this mean it is on for the 5 hour window and then going off again? Or is it coming on for some shorter time? And how did you spot this (logs, physically observed the LED, etc.)?

If you don't have anything scheduling your wifi on/off, this would be a rather unusual event.

No, I just woke up one morning ~ 8am to the additional glaring led, yesterday, it showed up sometime after 5 AM.. so the last time I noticed it Off was at 3 AM.

I was in the LuCi If all night, so on the wireless tab I kneejerked the disable button before gathering data.


The Edit:
I can manually trigger the radio's LED (On a disabled 'Radio0' with )

  • Using LuCi Channel Analysis
  • Using Wireless "Scan"

The manual triggering will occur on Disable Radios and with cli wifi down

Light come on and will not go off until I toggle Wireless Enable.

Why this occurs without user triggering is a mystery. Yet it seems the LED functions are not perfect as well as the odd mysterious ?untriggered? scans.

Was the radio entirely disabled (specifically, was the SSID disabled but radio still up, or was the radio down entirely)? And does the radio have a manual channel assignment or auto? If manual, what channel?

I've had it several states and it it now entirely disabled. Conducted the tests posted above.

Looked at chrissv thread and enable it, assigned channel 1 and conducted some cross reference test on mac's ~ hidden ssid.

This is were it was last evening after reading a thread chatting about a uci option to set "acs_num_scans", and how it was on post 1.
Clear as mud?

{
	"radio0": {
		"up": false,
		"pending": false,
		"autostart": false,
		"disabled": false,
		"retry_setup_failed": false,
		"config": {
			"path": "1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0",
			"band": "2g",
			"cell_density": 0,
			"txpower": 10,
			"htmode": "HT40",
			"channel": "acs_num_scans=10"
		},

So it looks like that could be related... worst case, you can simply reset your router to defaults and reconfigure without doing this extra stuff.

Respectfully disagree that if I don't reset this device to default and continue having the 2g light come on is related to making regular user adjustments. :slightly_smiling_face:

Sorry... maybe I didn't fully explain my thought process..
Resetting to defaults should solve the problem. From there, you can test specific settings (one at a time) to see which one(s) have triggered this behavior.

Do you mean resetting the Wireless? That's easy yes! agreed!

Flashing NO! SNAPSHOT hard pass.

You can reset to defaults without needing to reflash. But if you have user-installed packages, you may have difficulty reinstalling those packages (and thus you might then be in a situation where you need to flash the latest snapshot). Also worth noting that in some cases, there can be bugs in snapshots.... so if nothing else fixes it, maybe trying stable would make sense. (in fact, I always recommend stable over snapshot unless there is a specific reason you want/need to be on snapshot).

You can move the wireless file and then have the system regenerate a fresh config file. Make sure you have an ethernet connection since wifi will not be active by default.

I was being facetious. So you didn't mean to just redo the wireless?

I think you had said you were playing with the wifi scheduler, so resetting completely to defaults would clear that all out...

You can just redo wireless.... that is the least invasive method, but possibly the slower method in terms of fixing the issue (if it doesn't work, you'll have more work ahead of you). Lots of ways to do this, of course... depends on if you want the problem fixed right away, or if you want to try the least disruptive options first.

Yes I did play with this but this play was on day two of this LED issue, the package has been removed It's just a Cron job.. without the package.

I'd like to know what the issue is not just blanket wipe the system.

I've reset the wireless and made LuCi adjustments.

Thank you for clarifying.

Summary
{
	"radio0": {
		"up": false,
		"pending": false,
		"autostart": true,
		"disabled": true,
		"retry_setup_failed": false,
		"config": {
			"path": "1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0",
			"band": "2g",
			"cell_density": 0,
			"txpower": 10,
			"htmode": "HT40",
			"channel": "11",
			"disabled": true
		},
		"interfaces": [
			
		]
	},
	"radio1": {
		"up": true,
		"pending": false,
		"autostart": true,
		"disabled": false,
		"retry_setup_failed": false,
		"config": {
			"path": "1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1",
			"band": "5g",
			"cell_density": 0,
			"txpower": 11,
			"channel": "36",
			"htmode": "VHT80",
			"country": "US"
		},
		"interfaces": [
			{
				"section": "wifinet0",
				"ifname": "wlan1",
				"config": {
					"mode": "ap",
					"ssid": "Akita",
					"encryption": "psk2",
					"key": "Dada - Dizz Knee Land",
					"mode": "ap",
					"network": [
						"lan"
					]
				},
				"vlans": [
					
				],
				"stations": [
					
				]
			}
		]
	}
}

Understood. When working to find a root cause, you can work forwards or work backwards... to use an example, sometimes people have strange network failures where the entire network seems to go down for no good reason. In those cases, you can either stick with things as they are and unplug one device at a time to see if the problem resolves, or you can unplug everything and then plug things back in one at a time to see when the problem returns. Both can be useful and valid methods. So go with whichever is best for your situation.

It wont be long psherman, if the light comes on again, I know it wasn't me scanning.. and straight to cgi-bin/luci/admin/system/flash Preform Reset.

And if it happens again.. off to GitHub repository bug report. with my data.

1 Like

Related to this thread?

1 Like

I've been waiting on you.. no lie.

1 Like

Thanks for all the attention, I searched for this and used it today just because, learning new 'ease in's' is productive.

1 Like