Slow response of wireless switch

[vprasinos]

I like having the WPS switch assigned as a wifi switch. Switching on wifi used to take 1-2 secs in total in 270.26b. After pressing the WPS button the wifi leds would come up after 1 sec and the wifi would be instantly available.

I have upgraded from 270.26b to 374.33. Since then when i turn on wifi, the leds take from 6-8 seconds to turn on. However they turn off immediately if i switch it off i.e. the lag is noticed only when turning on wifi.

I upgraded to 374.34_2_sdk5, cleared manually the nvram (from ssh) and i have the same results. This is quite an annoyance because I want to know that the wifi is on when I am over the router since I take the tablet and go somewhere else in the house. I dont want to have to wait 8 seconds for me to find out that the wifi got switched on alright and that i can use it.

Needless to say that I have this behaviour having a totally clean router. I mean that if i run entware, transmission and jffs the same problem is still there, meaning that the wifi turn on procedure is not affected by any process taking cpu time.

What else can i try? Is anybody else having the same issue?

 

[CooCooCaChoo]

Why not leave the wifi on all the time? And have you tried confirming if the wifi is actually on and working even though the lights are indicating that it's not during the time period between turning it on and the LEDs coming?

 

[vprasinos]

Why should I check such a thing?! My concern is the speed of switching the wifi on and the leds confirming that it is on, within a second or so. I do not care if the wifi is switched on from second 0 to second 8. Maybe it is turned on, maybe not. The issue here is the speed of turning wifi on has reduced significantly when I upgraded the firmware.

And I can't have-don't want to have it on all the time, i have a baby in the house.

 

[RMerlin]

It takes whatever time it takes to the wireless driver to come up. There is nothing that can be done about this - enabling and starting a wireless interface just isn't instantaneous.

 

[vprasinos]

Meaning that the older wireless driver within 270.26b is more responsive?

Mind that I am using 374.34_2_sdk5 which - correct me if i am wrong - uses the same wireless driver as 270.26b..

 

[vprasinos]

I just tried 372.31 with same results. Here is the log file when I switch on the wireless:

Nov 18 00:07:52 rc_service: radio 702:notify_rc restart_wireless
Nov 18 00:07:55 kernel: device eth1 left promiscuous mode
Nov 18 00:07:55 kernel: br0: port 2(eth1) entering disabled state
Nov 18 00:07:55 kernel: device eth2 left promiscuous mode
Nov 18 00:07:55 kernel: br0: port 3(eth2) entering disabled state
Nov 18 00:07:57 kernel: wl_module_init: passivemode set to 0x0
Nov 18 00:07:57 kernel: eth1: Broadcom BCM4331 802.11 Wireless Controller 5.100.138.20
Nov 18 00:07:58 kernel: eth2: Broadcom BCM4331 802.11 Wireless Controller 5.100.138.20
Nov 18 00:07:58 kernel: device eth1 entered promiscuous mode
Nov 18 00:07:58 kernel: br0: port 2(eth1) entering listening state
Nov 18 00:07:58 kernel: br0: port 2(eth1) entering learning state
Nov 18 00:07:58 kernel: br0: topology change detected, propagating
Nov 18 00:07:58 kernel: br0: port 2(eth1) entering forwarding state
Nov 18 00:07:58 kernel: device eth2 entered promiscuous mode
Nov 18 00:07:58 kernel: br0: port 3(eth2) entering listening state
Nov 18 00:07:58 kernel: br0: port 3(eth2) entering learning state
Nov 18 00:07:58 kernel: br0: topology change detected, propagating
Nov 18 00:07:58 kernel: br0: port 3(eth2) entering forwarding state

As you notice I press the button at 00:07:52 and the LEDs turn on only at 00:07:58 (six seconds later) when the driver has been initialised.

What happens exactly above? Is this log normal? Why do 3 seconds pass from the "notify_rc restart_wireless" until the "device eth1 (and eth2) left promiscuous mode" ? Why do they have to be disabled first so that they get enabled 4 seconds later?

 

[RMerlin]

Meaning that the older wireless driver within 270.26b is more responsive?

Mind that I am using 374.34_2_sdk5 which - correct me if i am wrong - uses the same wireless driver as 270.26b..

Or the LEDs were turned on before the radio was actually up and running.

 

[RMerlin]

I just tried 372.31 with same results. Here is the log file when I switch on the wireless:

Nov 18 00:07:52 rc_service: radio 702:notify_rc restart_wireless
Nov 18 00:07:55 kernel: device eth1 left promiscuous mode
Nov 18 00:07:55 kernel: br0: port 2(eth1) entering disabled state
Nov 18 00:07:55 kernel: device eth2 left promiscuous mode
Nov 18 00:07:55 kernel: br0: port 3(eth2) entering disabled state
Nov 18 00:07:57 kernel: wl_module_init: passivemode set to 0x0
Nov 18 00:07:57 kernel: eth1: Broadcom BCM4331 802.11 Wireless Controller 5.100.138.20
Nov 18 00:07:58 kernel: eth2: Broadcom BCM4331 802.11 Wireless Controller 5.100.138.20
Nov 18 00:07:58 kernel: device eth1 entered promiscuous mode
Nov 18 00:07:58 kernel: br0: port 2(eth1) entering listening state
Nov 18 00:07:58 kernel: br0: port 2(eth1) entering learning state
Nov 18 00:07:58 kernel: br0: topology change detected, propagating
Nov 18 00:07:58 kernel: br0: port 2(eth1) entering forwarding state
Nov 18 00:07:58 kernel: device eth2 entered promiscuous mode
Nov 18 00:07:58 kernel: br0: port 3(eth2) entering listening state
Nov 18 00:07:58 kernel: br0: port 3(eth2) entering learning state
Nov 18 00:07:58 kernel: br0: topology change detected, propagating
Nov 18 00:07:58 kernel: br0: port 3(eth2) entering forwarding state

As you notice I press the button at 00:07:52 and the LEDs turn on only at 00:07:58 (six seconds later) when the driver has been initialised.

What happens exactly above? Is this log normal? Why do 3 seconds pass from the "notify_rc restart_wireless" until the "device eth1 (and eth2) left promiscuous mode" ? Why do they have to be disabled first so that they get enabled 4 seconds later?

That's because the router is based on a series of internal services that get restarted to accommodate configuration changes. When the wireless service is restarted, it also restarts a series of linked services such as LAN.

 

[CooCooCaChoo]

So basically you have a baby monitor that may interfere with wireless operations? Why not schedule the wireless interface to come up and go down automatically according to the schedule of the baby monitor's usage?

 

[vprasinos]

> CooCooCaChoo
No I don't. I just want to be turning wifi off to reduce emf. And I don't use any baby monitor for that reason. I turn on and off the wifi only when I need it and I want the switch to respond fast for that reason.

> RMerlin
Thanks for your clear answer. However I got more puzzled. I downgraded to 270.26b and the behaviour of the WPS (wireless) switch returned to being snappy again. I noticed though that there is no log of me turning on and off the wireless in the system log. Maybe this is the reason for the switch being snappy?

What I want to accomplish is have the latest 374.34_2 (mainly for the aidisk issues) but have the snappy wifi on off. From what I suspect, the culprit maybe in disabling the wireless on-off log in 374.34_2. Can this be done? I don't care if the wireless driver gets activated at the time of the pressing of the button, I only want the leds to give me visual confirmation that I pressed the switch, the actual turning on can come seconds later, I don't mind.