Opened 7 years ago

Closed 4 years ago

#5699 closed (invalid)

ddwrt channel listing for qualcomm 5ghz is a mess & incorrect

Reported by: tatsuya46 Owned by:
Keywords: Cc:

Description

our channel list for qca is incorrect & messy, displaying a bunch of invalid channel combos. using r7800 as reference, & assuming a reg domain that supports all channels 36-165 is used, these are the only channels that should be displayed when the user is using X channel width with Y extension channel setting.

invalid example: when using vht80+upper, invalid channels such as 56, 60, 153, etc are displayed. directly setting these channels is invalid as gui isnt updated to support upper lower/lower upper configs on qualcomm like for broadcom. therefor qualcomm units try to use in the case of 153, 153+157+161+165 = invalid, vht80 isnt used.

vht80+lower

  • 48
  • 64
  • 112
  • 128
  • 144
  • 161

vht80+upper

  • 36
  • 52
  • 100
  • 116
  • 132
  • 149

vht160+lower

  • 64
  • 128

vht160+upper

  • 36
  • 100

(v)ht40+lower

  • 40
  • 48
  • 56
  • 64
  • 104
  • 112
  • 120
  • 128
  • 136
  • 144
  • 153
  • 161

(v)ht40+upper

  • 36
  • 44
  • 52
  • 60
  • 100
  • 108
  • 116
  • 124
  • 132
  • 140
  • 149
  • 157

(v)ht20, all 36~165

Attachments (4)

bsbuild_qca.png (3.6 KB ) - added by tatsuya46 7 years ago.
kongbuild_qca.png (8.5 KB ) - added by tatsuya46 7 years ago.
ath10k channels ALL.txt (6.0 KB ) - added by tatsuya46 7 years ago.
dd-wrt 5Ghz bug 1.png (210.2 KB ) - added by Brian Gregory 7 years ago.
Screenshot dd-wrt 5GHz wireless bug

Download all attachments as: .zip

Change History (54)

comment:1 by tatsuya46, 7 years ago

Resolution: invalid
Status: newclosed

comment:2 by tatsuya46, 7 years ago

Resolution: invalid
Status: closedreopened

comment:3 by tatsuya46, 7 years ago

kong build has taken a huge leap in cleaning this up

comment:4 by BrainSlayer, 7 years ago

Resolution: worksforme
Status: reopenedclosed

56, 60, 153 are valid. dont think that broadcom is valid on all points.the channels which are displayed are all checked if parent ht40 and ht20 exist in full channel spacing. according to this lower / upper or one of these if offered or the whole channel isnt displayed.

comment:5 by BrainSlayer, 7 years ago

56 and 60 upper is not even offered. for 153 i need to check. 

comment:6 by tatsuya46, 7 years ago

Resolution: worksforme
Status: closedreopened

thats not what i mean. because ddwrt only lets qca pick PURE upper or PURE lower (primary + 2nd + 3rd + 4th) or (primary - 2nd - 3rd - 4th). channels 40, 44, 56, 60, 104, 108, 120, 124, 136, 140, 153, 157, 165 are all invalid for vht80, for the current logic used with qualcomm. while 165 is invalid on everything except ht20.

if we can select upper upper/lower lower/upper lower/lower upper etc like broadcom, then those channels CAN be valid too. but not in a strict pure upper or pure lower or else its out of bounds & doesnt broadcast or uses partial channels. this should be possible on qca because r7800 when 149+upper is chosen, it uses 153+155, which IS valid, yes. but its not what the radio was commanded to do, 1/10 boots it will actually use what i picked, 149(+155). having the primary on the 2nd channel (1st + primary + 3rd + 4th), this means ath10k fw & driver can do it. its doing it on its own on 149 for some reason when not told to. this also happens to qca9880 devices.

see these images below, ipq806x on vht80 only. kong build has the correct, bs build has full options but half are not usable on qca.

Last edited 7 years ago by tatsuya46 (previous) (diff)

by tatsuya46, 7 years ago

Attachment: bsbuild_qca.png added

by tatsuya46, 7 years ago

Attachment: kongbuild_qca.png added

comment:7 by BrainSlayer, 7 years ago

channel 153 is valid too, for some reason the firmware does no accept it.

  • 5765 MHz [153] (30.0 dBm)
  • 5785 MHz [157] (30.0 dBm)
  • 5805 MHz [161] (30.0 dBm)
  • 5825 MHz [165] (30.0 dBm)

so 153 has clearly 4x20mhz channels available. need to check whats wrong on ath10k side, in theory it must work and this is what matters at the end. 165 is valid for lower for sure. one problem is

  • 5720 MHz [144] (23.0 dBm)
  • 5745 MHz [149] (30.0 dBm)

see the 25 mhz cap? this turns channels invalid which are overlapping in this area. for me it makes no sense to over overlapping center and control channels since this would not result in 80 mhz channel space

comment:8 by BrainSlayer, 7 years ago

Resolution: provide more info and reopen
Status: reopenedclosed

comment:9 by BrainSlayer, 7 years ago

and i see no relation between your screenshots. kong uses the same sourcecodes like me. but his channel list looks clearly wrong if channel 108 is missing

comment:10 by tatsuya46, 7 years ago

Resolution: provide more info and reopen
Status: closedreopened

if 153 is set directly then its wrong because center of 159 is created, devices dont use vht80 then.. try setting 108 & 165 with vht80, upper or lower, does not work cause they are invalid, wrong center is created. 165 is also a ht20 only channel, this chart has it right http://twimgs.com/networkcomputing/news/2013/10/graphic-80211-acChannels-all.png

so the channels on kong build are correct & all work properly with all 80mhz being used, vht160 selection is also correct.

comment:11 by tatsuya46, 7 years ago

see attached .txt for full results of testing. it is a little better, but theres still many invalid options being displayed. i listed out all the valid options & all the invalid options.

example: 64+LU is invalid cause, primary "64", lower (L) being "60" and "56" below primary, then upper (U) being "???" there is no upper channel above 64. numerical order comes out to be 56(L)+60(L)+64(P)+???(U) = invalid center freq & rejected by ath10k fw. since as of the current way u are doing lowers & uppers, the first letter "L" means 2 channels below the primary, the next letter "U" means 1 channel above the primary, the first letter means 2 above or below, the second letter means 1 above or below. so in this example, the lower side is valid, the upper side is invalid, thus invalidates the entire config.

example 2: 136+UL is valid, first we picked primary, "136". now "U" means 2 upper channels above primary so "140" and "144". and "L" means 1 channel lower than primary, "132". so in numerical order it comes out as 132(L)+136(P)+140(U)+144(U) = 138(C). so 136+138, & is valid. the same center makes it valid as we got previously when only pure upper, 132(P)+136(U)+140(U)+144(U) = 138(C), or pure lower 144(P)+140(L)+136(L)+132(L) = 138(C).

example 3: only 112+LL is valid, as there is no space above 112 for even 1 U channel without invalidating the current spectrum portion AND the next one above it too, 112 is a pure lower only channel. opposite of that is 116, only 116+UU is valid as there is no space below it for even 1 L channel without invalidating the current spectrum portion & one below it.

the exception is when we get to 149 & 157. for some reason its stuck on using 153 as primary, bug somewhere. but at least the center stays valid on 155 so it does work. when we get to 161+LL is only when the primary will finally move off of 153. and 165 is plain invalid, even on ht40. its an ht20 only channel.

if u look closely at the valid config list, u can see the pattern. all we need to do is remove those from the invalid list, & we will be mostly good to go, no more users setting invalid channels, for vht80 at least.

Last edited 7 years ago by tatsuya46 (previous) (diff)

by tatsuya46, 7 years ago

Attachment: ath10k channels ALL.txt added

comment:12 by mrjcd, 7 years ago

Findings are a bit different on the EA8500 w/r31272 Only tested channels 108/165/161/149/36 listed in pic. All available selections for these channels are shown. Only tested in VTH80 .. seeing what the GUI shows. http://mrjcd.com/junk/dd-wrt/EA8500/31272/31272_ch.png All connected fine to the droid turbo phone... but for the obvious that killed ath1_hostap. and yea the openVPN server still works -

Using US reg domain

Last edited 7 years ago by mrjcd (previous) (diff)

comment:13 by tatsuya46, 7 years ago

some of urs were invalid, ath10k fw 10.4.3 & 10.2.4 are kind of dumb & wont reject invalid combos, like 10.4-3.4 does. so for u they will broadcast, but do so invalidly, only getting ht20 or ht40 at most but never vht80. if u have any ac devices, connect it and do local speed checks, or look at wireless status page, when using 161+LU, it will never go to vht80 cause center is invalid for 80mhz, so will only connect on the channel(s) that are valid within it, either 20 or 40mhz worth.

dir-862L & qca9880 functions this same way, broadcasting even wrong combos.

Last edited 7 years ago by tatsuya46 (previous) (diff)

comment:14 by mrjcd, 7 years ago

EA8500 w/r31277 after factory reset or erase nvram All channels using HT40 lower only broadcast HT20. Affects both ath0 & ath1 -- does NOT affect VHT80. e.g. CH6 HT40 lower broadcast HT20 / CH 6 HT40 upper is good / CH 1 HT40 upper good / Ch 11 HT40 lower broadcast HT20 / 161 HT40 lower broadcast HT20 / 36 HT40 upper good / 108 HT40 lower broadcast HT20 / 108 HT40 upper good. Aslo same issue w/WNDR3700v4 after reset or if you ever change pre conf wireless settings. Have a wndr3700v4 up 6:15 install r31277 over pre conf using CH 5 lower all good / 161 lower all good broadcasting HT40 but have not touched its wireless conf.

in reply to:  13 comment:15 by mrjcd, 7 years ago

Replying to tatsuya46:

some of urs were invalid, ath10k fw 10.4.3 & 10.2.4 are kind of dumb & wont reject invalid combos, like 10.4-3.4 does. so for u they will broadcast, but do so invalidly, only getting ht20 or ht40 at most but never vht80. if u have any ac devices, connect it and do local speed checks, or look at wireless status page, when using 161+LU, it will never go to vht80 cause center is invalid for 80mhz, so will only connect on the channel(s) that are valid within it, either 20 or 40mhz worth.

dir-862L & qca9880 functions this same way, broadcasting even wrong combos.

Yea just showing what I see --

comment:16 by tatsuya46, 7 years ago

Resolution: invalid
Status: reopenedclosed

comment:17 by tatsuya46, 7 years ago

Resolution: invalid
Status: closedreopened

comment:18 by BrainSlayer, 7 years ago

Resolution: worksforme
Status: reopenedclosed

i disagree. i tested these combos you declared as invalid using a secondary r7800 unit using the same firmware. vht80 isnt a problem with it. so please do use 2 identical fw based devices. i t ested on 9984. and yes there is a issue with buggy client device firmwares from different vendors. so the channel combinations i show in dd-wrt do all work in the selected operation modes. just use a compatible device. and dont blame me for adding the new channel combinations i just added for you. it was painfull to implement them all and to change the channel calculation algorithm

comment:19 by tatsuya46, 7 years ago

Resolution: worksforme
Status: closedreopened

i said it was a little better there was no blame. u should not use another ddwrt device for testing channels, use a different device like a laptop, tablet, etc, something that follows 802.11 spec. testing with another ddwrt device makes it hard cause ddwrt has invalid options, so connecting ddwrt to another ddwrt router will make it appear everythings fine, because it accepts any connection invalid or not.

eg: 165 is an ht20 only channel, but cause ddwrt thinks its valid, using another ddwrt device will result in a connection, while all the other devices do not connect or use 80mhz worth cause it violates 802.11 spec. any violation of the spec & channel portions shown here http://twimgs.com/networkcomputing/news/2013/10/graphic-80211-acChannels-all.png will result in devices not connecting, not using full 80mhz bandwidth, or no radio broadcast. as the chart shows for example, vht80 128 is LL only, 52 is UU only. if u try to do UL, LU, or LL on 52, it bleeds over into the 36-48 spectrum space below it & breaks spec.

ddwrt is not following channel spec so u are being tricked by using ddwrt <-> ddwrt to test whats valid. test with your mac, iphone, any other 802.11ac device, u will quickly see the invalid combos. try again testing those i listed as invalid with another device. will be no radio broadcast, or the device wont use vht80.

Last edited 7 years ago by tatsuya46 (previous) (diff)

comment:20 by tatsuya46, 7 years ago

same stands for current standings, better but still many invalid offering are listened.

comment:21 by tatsuya46, 7 years ago

Resolution: invalid
Status: reopenedclosed

comment:22 by tatsuya46, 7 years ago

Resolution: invalid
Status: closedreopened

comment:23 by tatsuya46, 7 years ago

Resolution: invalid
Status: reopenedclosed

comment:24 by tatsuya46, 7 years ago

Resolution: invalid
Status: closedreopened

brainslayer, u are still providing invalid channels, could u please check this against 802.11 spec.

EG: channel 165 is *20mhz ONLY*! ch 161 is LL (80 MHz & 40 MHz) ONLY, look at the channel specs, u CANT go ABOVE 161 on anything over 20 MHz & have VALID, channel spec, no spectrum space. same thing for many other channels.. the center freq will go out of bounds! ask on ath10k mailing list if u dont believe me. link to this ticket.

the point of this ticket is to REMOVE all INVALID, channels, yes u did lots of work recently for LU/UL/UUU etc, thank u for that, but we need to ONLY have VALID offerings in gui.

look at broadcom, they have all LL/UL/LU/UU etc correct. please try with any 802.11ac device such as iphone 6+ etc, they will show u i am correct in listing valid vht80 channels.. do NOT, use ddwrt <-> ddwrt repeater for testing. ddwrt currently accepts INVALID configs, so invalid + invalid = u think it "works". u are being tricked by ur own firmware..

http://svn.dd-wrt.com/attachment/ticket/5699/ath10k%20channels%20ALL.txt

remember qca9880 & qca9980 fw is STUPID, they will broadcast INVALID center freq. only qca9984 fw is smart & knows whats valid & invalid.

Last edited 7 years ago by tatsuya46 (previous) (diff)

comment:25 by tatsuya46, 7 years ago

after i saw this: http://www.dd-wrt.com/phpBB2/viewtopic.php?p=1070270#1070270

u stated available channels in germany, i guess they opened up, way up. looking at that ya u should be able to go over 161 with 40/80/160mhz. we cannot using canada/usa/haiti/grenada etc. the valid/invalid list i provided is for any reg domain supporting the following channels, 36-48, 52-64, 100-144, 149-161, 165.

i did state what reg domain was being used in my results .txt file. ddwrt doesnt have the logic to determine the current reg domain in use, & apply correct channel configs for that reg domain.

now this is sort of making sense, u were testing with germany reg domain, werent u bs?

if so, what i stated should still be correct, but AFTER, ch 161, is where the changes happen. i think this is why we were getting confused.

Last edited 7 years ago by tatsuya46 (previous) (diff)

comment:26 by tatsuya46, 7 years ago

Resolution: invalid
Status: reopenedclosed

comment:27 by tatsuya46, 7 years ago

Resolution: invalid
Status: closedreopened

by Brian Gregory, 7 years ago

Attachment: dd-wrt 5Ghz bug 1.png added

Screenshot dd-wrt 5GHz wireless bug

comment:28 by Brian Gregory, 7 years ago

5GHz HT40 is messed up on my WNDR3700v2 with r32170 (also a few previous builds)

36+upper and 100+upper work right but for instance:

44+upper usually gets me 48+44 which works but is not what I asked for. However sometimes I do get 44+48 (correct) also sometimes I get some unknown frequency that nothing will connect to. Also sometimes the bit where you choose you channel goes crazy and offers me not just multiples of 4 (which, as I understand it, is correct) but sometimes every number starting at 36!!! It happens seemingly randomly. See attached screenshot "dd-wrt 5Ghz bug 1.png​".

comment:29 by Brian Gregory, 7 years ago

Resolution: provide more info and reopen
Status: reopenedclosed

comment:30 by Brian Gregory, 7 years ago

Resolution: provide more info and reopen
Status: closedreopened

comment:31 by tatsuya46, 7 years ago

Resolution: invalid
Status: reopenedclosed

comment:32 by tatsuya46, 7 years ago

Resolution: invalid
Status: closedreopened

ll, ul etc we should have them renamed to proper wording, lower lower, upper lower, etc like broadcom. easier for users to understand, delete "-/+#" to save font space.

the lower/upper & combos is part of 802.11ac spec, basically just follow how it is with broadcom & stock firmwares, its correct there. any vendor contact u have should be able to help u know that our current way for qca is broken (161 is ONLY lower lower for most reg domains, like haiti, canada, usa etc)

please see comment above: http://svn.dd-wrt.com/ticket/5699#comment:25 this should be most of the confusion here. u need to test with a few more reg domains, not just germany. the current logic is trying to apply to reg domains where its invalid (eg: ch 161 example above, but others such as ch 60 etc, are still listing invalid options, 60 is lower upper ONLY, when using 80mhz).

these are the valid channel configs for 80mhz in reg domains such as haiti etc, where the FULL dfs mid band 100-144 is offered. reg domains such as australia, canada etc will have slightly less as channels around 120 are not allow in current reg domain settings. germany will have special options above 161 for >20mhz.

  • 36 + upper upper
  • 40 + upper lower
  • 44 + lower upper
  • 48 + lower lower
  • 52 + upper upper
  • 56 + upper lower
  • 60 + lower upper
  • 64 + lower lower
  • 100 + upper upper
  • 104 + upper lower
  • 108 + lower upper
  • 112 + lower lower
  • 116 + upper upper
  • 120 + upper lower
  • 124 + lower upper
  • 128 + lower lower
  • 132 + upper upper
  • 136 + upper lower
  • 140 + lower upper
  • 144 + lower lower
  • 149 + upper upper
  • 153 + upper lower
  • 157 + lower upper
  • 161 + lower lower

this example reg domain used is haiti which offers every channel from 36 to 165 in 20mhz. nothing more or less is allowed than these listed settings for 80mhz. 165 should only be listed to the user when using 20mhz, its a 20mhz only channel. for germany its a 40mhz channel, possibly 80mhz.

comment:33 by BrainSlayer, 6 years ago

Resolution: invalid
Status: reopenedclosed

nope. wont to it. you know how this will look with vht160? there is a reason why i shorted it

comment:34 by BrainSlayer, 6 years ago

and 165 is no vht80 channel. the cap is the problem. there is no valid side channel available here. there is a channel spacing of 5 mhz per channel required. hostapd will not accept it otherwise. 20 mhz = 4 channels. but now look at channel 144 and 149 . thats 5 channels distance. so the site channel will hit a hole. in germany its a 9 channel hole 140 and 149 is the next one

comment:35 by BrainSlayer, 6 years ago

for your list. 60 works with lower lower too. same for 56. why do you think that only a single combination is supported. this is wrong. there can be multiple choices

comment:36 by tatsuya46, 6 years ago

Resolution: invalid
Status: closedreopened

60 is lower upper only..

60+LL = 60+56+52+?? = out of bounds, devices dont do vht80. this is what im saying, in channel 60 example only 60+LU is proper (for vht80), and for 56 only 56+UL is proper, see what im getting at.

dont test with ddwrt router <--> ddwrt router, it will appear to work cause invalid + invalid = they see the same. check it with a real client device like a 802.11ac phone, tablet, laptop etc. u will see they will not do vht80. ask any vendor, netgear, asus, broadcom, qualcomm, mediatek etc. everyone has the channels offered correct.

it doesnt look like u tested with other reg domains like usa, haiti etc. we have this correct on broadcom last time i looked.

using 161+LL vht80 right now with haiti reg domain, yet it still offers me 161+LU which is impossible, this is not germany reg domain, there is no room above 161 for 80mhz, so its lower lower ONLY..

Last edited 6 years ago by tatsuya46 (previous) (diff)

comment:37 by tatsuya46, 6 years ago

Resolution: invalid
Status: reopenedclosed

comment:38 by tatsuya46, 6 years ago

Resolution: invalid
Status: closedreopened

the ext channel selection is even worse now with r33599.. EG: lower options with 36 & 100..? we all know this is impossible... but every channel is like this now. mostly wrong options, only 1 correct option

comment:39 by tatsuya46, 6 years ago

Resolution: invalid
Status: reopenedclosed

comment:40 by tatsuya46, 6 years ago

Resolution: invalid
Status: closedreopened

comment:41 by tatsuya46, 6 years ago

Resolution: invalid
Status: reopenedclosed

comment:42 by tatsuya46, 6 years ago

Resolution: invalid
Status: closedreopened

r35244 now the channel list shows every single channel when using vht80.. totally bullshit, thats only when using 20mhz not 80mhz...

comment:43 by jeremywh7, 6 years ago

Hey tatsuya, perhaps the graphics in this link would help in describing the allowed channel bondings (note this is from 2013 though, so you'll have to account for FCC changes since then):

http://securityuncorked.com/2013/11/the-best-damn-802-11ac-channel-allocation-graphics/

Last edited 6 years ago by jeremywh7 (previous) (diff)

comment:44 by tatsuya46, 6 years ago

remains r35384..

i tried demonstrating that graph before, along with multiple others. nothing seems to convince brainslayer, still thinks 149 for example has lower space in 80mhz, etc...

comment:45 by Brian Gregory, 6 years ago

Does Changeset 36797 perhaps address something to do with this?
https://svn.dd-wrt.com/changeset/36797

Last edited 6 years ago by Brian Gregory (previous) (diff)

in reply to:  37 comment:46 by ho1Aetoo, 5 years ago

..

Last edited 5 years ago by ho1Aetoo (previous) (diff)

comment:47 by tatsuya46, 5 years ago

Resolution: invalid
Status: reopenedclosed

comment:48 by tatsuya46, 5 years ago

Resolution: invalid
Status: closedreopened

this is still in dire need of cleaning up.. its not that complicated.. we have our ht40+/- backwards when using vht80 UL/LU.. and remove the invalid options.

us reg domain, 80mhz, 161+UU? really...? 161 is LL ONLY.. we apply this crap logic to all the channels.. 36 is UU only, but has a UL option which is invalid..

comment:49 by Ultra9k, 5 years ago

Yes, this clearly needs fixing. Please read: https://svn.dd-wrt.com/ticket/6801

comment:50 by tatsuya46, 4 years ago

Resolution: invalid
Status: reopenedclosed

this isnt needed anymore

Note: See TracTickets for help on using tickets.