[RT-N66U 380.58] Cannot set channel to 12 or 13 in the 2.4GHz band

[episyron]

Hi,

I tried to change the control channel to more quiet 13 in the wireless 2.4GHz band, but although 12 and 13 control channels are on the list to be selected, after selecting 13 the control channel changes to Auto (and picks the channel 6) and a channel bandwidth changes from 20Hz to 20/40Hz. So they seem to reset to defaults. The wireless mode was before and after Auto. Channels 12 and 13 are legitimate channels in this part of the world. To my eye there seems to be nothing relevant in the system log:

Apr 26 11:57:36 rc_service: httpd 258:notify_rc restart_wireless
Apr 26 11:57:37 kernel: br0: port 2(eth1) entering disabled state
Apr 26 11:57:37 kernel: device eth1 left promiscuous mode
Apr 26 11:57:37 kernel: br0: port 2(eth1) entering disabled state
Apr 26 11:57:38 kernel: br0: port 3(eth2) entering disabled state
Apr 26 11:57:38 kernel: device eth2 left promiscuous mode
Apr 26 11:57:38 kernel: br0: port 3(eth2) entering disabled state
Apr 26 11:57:38 kernel: br0: port 4(wl0.1) entering disabled state
Apr 26 11:57:38 kernel: device wl0.1 left promiscuous mode
Apr 26 11:57:38 kernel: br0: port 4(wl0.1) entering disabled state
Apr 26 11:57:38 kernel: br0: port 5(wl1.1) entering disabled state
Apr 26 11:57:38 kernel: device wl1.1 left promiscuous mode
Apr 26 11:57:38 kernel: br0: port 5(wl1.1) entering disabled state
Apr 26 11:57:38 kernel: wl_module_init: passivemode set to 0x0
Apr 26 11:57:38 kernel: eth1: Broadcom BCM4331 802.11 Wireless Controller 6.30.163.2002 (r382208)
Apr 26 11:57:38 kernel: eth2: Broadcom BCM4331 802.11 Wireless Controller 6.30.163.2002 (r382208)
Apr 26 11:57:39 kernel: device eth1 entered promiscuous mode
Apr 26 11:57:39 kernel: br0: port 2(eth1) entering learning state
Apr 26 11:57:39 kernel: br0: topology change detected, propagating
Apr 26 11:57:39 kernel: br0: port 2(eth1) entering forwarding state
Apr 26 11:57:39 kernel: device eth2 entered promiscuous mode
Apr 26 11:57:39 kernel: br0: port 3(eth2) entering learning state
Apr 26 11:57:39 kernel: br0: topology change detected, propagating
Apr 26 11:57:39 kernel: br0: port 3(eth2) entering forwarding state
Apr 26 11:57:39 kernel: device wl0.1 entered promiscuous mode
Apr 26 11:57:39 kernel: br0: port 4(wl0.1) entering learning state
Apr 26 11:57:39 kernel: br0: topology change detected, propagating
Apr 26 11:57:39 kernel: br0: port 4(wl0.1) entering forwarding state
Apr 26 11:57:39 kernel: device wl1.1 entered promiscuous mode
Apr 26 11:57:39 kernel: br0: port 5(wl1.1) entering learning state
Apr 26 11:57:39 kernel: br0: topology change detected, propagating
Apr 26 11:57:39 kernel: br0: port 5(wl1.1) entering forwarding state

 

[pete y testing]

Channels 12 and 13 are legitimate channels in this part of the world.

but are the adapter capable of it

we recommend not using ch 12 or 13 because of incompatibility issues with client adapters

if 2.4 gig is that noisy use 5 gig as thats what its there for , if your clients are only 2.4 gig its prob time to upgrade them

 

[Shonk]

but are the adapter capable of it

we recommend not using ch 12 or 13 because of incompatibility issues with client adapters

if 2.4 gig is that noisy use 5 gig as thats what its there for , if your clients are only 2.4 gig its prob time to upgrade them

I have never run into an adapter thats incapable of using channel 12 and 13

it may cause issues for users using that use channel illegally but for people in the correct region
its fine (the adapter usually polls the os region)

 

[Shonk]

Hi,

I tried to change the control channel to more quiet 13 in the wireless 2.4GHz band, but although 12 and 13 control channels are on the list to be selected, after selecting 13 the control channel changes to Auto (and picks the channel 6) and a channel bandwidth changes from 20Hz to 20/40Hz. So they seem to reset to defaults. The wireless mode was before and after Auto. Channels 12 and 13 are legitimate channels in this part of the world. To my eye there seems to be nothing relevant in the system log:

Try these settings

 

[episyron]

but are the adapter capable of it

we recommend not using ch 12 or 13 because of incompatibility issues with client adapters

if 2.4 gig is that noisy use 5 gig as thats what its there for , if your clients are only 2.4 gig its prob time to upgrade them

Actually I have used channel 13 for long time successfully with my clients and a stock ASUS firmware. It is quite nice to have channel 13 available, having 4 non-overlapping channels instead of 3. I had to change the channel as Raspberry Pi 3 didn't support upper channels at first. Well now it is fixed in RasPi3 so it was time to change the channel back to 13 and in the mean time I upgraded to merlin 380.58.

I am more than willing to change to 5GHz, but in this household there are too many clients in 2.4GHz to make total switch, regret to say even new hardware. But I'm not gonna go back to the ASUS factory firmware for this, preferring merlin's...

 

[pete y testing]

the use of ch 12 and 13 are of little use in avoiding congesting as they overlap ch 11 , there are only 3 usable channels that do not overlap and thats ch 1 , 6 or 11

 

[pete y testing]

having 4 non-overlapping channels instead of 3.

as above ch 12 and 13 overlap ch 11 , so its not a 4th non overlapping setup

it is only non overlapping if ch 14 is selected which is only available in japan and thats if 20 mhz is selected

 

[Shonk]

There is only 2 non overlapping channels for 40mhz in an eu region
1 Above or 5 Below
and
13 Below or 9 Above

for the US there's no way to not overlap.

There is plenty reason to use channel 13 people in the eu tend to not use 11 at all

the use of ch 12 and 13 are of little use in avoiding congesting as they overlap ch 11 , there are only 3 usable channels that do not overlap and thats ch 1 , 6 or 11

 

[pete y testing]

There is plenty reason to use channel 13 people in the eu tend to not use 11 at all

and that still overlaps with ch 11 so your argument doesnt stand up , it is still overlapping on 20mhz

again the choice of ch 12 or 13 does not and will not give you a 3rd or 4th non overlapping channel set and so the reason to choose it has no validity

 

[Shonk]

Your thinking as an american
if you had access to 1-13

the recomended channels would be as i said

there's 80 mhz of bandwidth non overlapping
ofc its overlapping channel 11 its using channel 7 - 13

or you can split that up into 4 x 20mhz chunks

and that still overlaps with ch 11 so your argument doesnt stand up , it is still overlapping on 20mhz

again the choice of ch 12 or 13 does not and will not give you a 3rd or 4th non overlapping channel set and so the reason to choose it has no validity

 

[episyron]

Try these settings

Thanks for the interesting suggestion. However I cannot change extension channel to above, it returns to below. You seem to have 380.59, fixed there? Can you select 12 or 13 with 20MHz bandwidth?

 

[Shonk]

will try now

 

[Shonk]

yes works fine

 

[pete y testing]

or you can split that up into 4 x 20mhz chunks

sigh

see

https://en.wikipedia.org/wiki/List_of_WLAN_channels

the first 2 images

 

[Shonk]

Yes i know look again
1, 5, 9 , 13

geez man

Your quoting the best workaround for 1-11 users
which is 1, 6, 11

we have a full 80mhz of spectrum so its

1, 5, 9, 13

Rest OF World

Here's me on 11
see how im overlapping into the device on channel 1
its not hard to work out

sigh

see

https://en.wikipedia.org/wiki/List_of_WLAN_channels

the first 2 images

 

[episyron]

yes works fine

OK, thanks! So just have to wait for 380.59 for RT-N66U and hope it works here too...

 

[Shonk]

OK, thanks! So just have to wait for 380.59 for RT-N66U and hope it works here too...

np

 

[Shonk]

Nice to see some Humble and admit when they are wrong
Instead of just walking off

 

[sfx2000]

There is only 2 non overlapping channels for 40mhz in an eu region
1 Above or 5 Below
and
13 Below or 9 Above

for the US there's no way to not overlap.

There is plenty reason to use channel 13 people in the eu tend to not use 11 at all


View attachment 6131

Would be interesting to see with a spectrum analyzer to see if that channel is actually used much...

12/13 would be great to use here in North America, as with this, one could actually do some interesting things that are in the small print and actually deploy a single 80MHz channel...

 

[Shonk]

I already upset my neighbours with 2x40mhz channels they would love a single 80mhz one even more