Opened 2 months ago

Last modified 3 weeks ago

#5699 reopened

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 (3)

bsbuild_qca.png (3.6 KB) - added by tatsuya46 8 weeks ago.
kongbuild_qca.png (8.5 KB) - added by tatsuya46 8 weeks ago.
ath10k channels ALL.txt (6.0 KB) - added by tatsuya46 8 weeks ago.

Download all attachments as: .zip

Change History (30)

comment:1 Changed 8 weeks ago by tatsuya46

  • Resolution set to invalid
  • Status changed from new to closed

comment:2 Changed 8 weeks ago by tatsuya46

  • Resolution invalid deleted
  • Status changed from closed to reopened

comment:3 Changed 8 weeks ago by tatsuya46

kong build has taken a huge leap in cleaning this up

comment:4 Changed 8 weeks ago by BrainSlayer

  • Resolution set to worksforme
  • Status changed from reopened to closed

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 Changed 8 weeks ago by BrainSlayer

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

comment:6 Changed 8 weeks ago by tatsuya46

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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 8 weeks ago by tatsuya46 (previous) (diff)

Changed 8 weeks ago by tatsuya46

Changed 8 weeks ago by tatsuya46

comment:7 Changed 8 weeks ago by BrainSlayer

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 Changed 8 weeks ago by BrainSlayer

  • Resolution set to provide more info and reopen
  • Status changed from reopened to closed

comment:9 Changed 8 weeks ago by BrainSlayer

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 Changed 8 weeks ago by tatsuya46

  • Resolution provide more info and reopen deleted
  • Status changed from closed to reopened

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 Changed 8 weeks ago by tatsuya46

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 8 weeks ago by tatsuya46 (previous) (diff)

Changed 8 weeks ago by tatsuya46

comment:12 Changed 7 weeks ago by mrjcd

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 weeks ago by mrjcd (previous) (diff)

comment:13 follow-up: Changed 7 weeks ago by 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.

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

comment:14 Changed 7 weeks ago by mrjcd

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.

comment:15 in reply to: ↑ 13 Changed 7 weeks ago by mrjcd

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 Changed 7 weeks ago by tatsuya46

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:17 Changed 7 weeks ago by tatsuya46

  • Resolution invalid deleted
  • Status changed from closed to reopened

comment:18 Changed 7 weeks ago by BrainSlayer

  • Resolution set to worksforme
  • Status changed from reopened to closed

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 Changed 7 weeks ago by tatsuya46

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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.

Version 0, edited 7 weeks ago by tatsuya46 (next)

comment:20 Changed 6 weeks ago by tatsuya46

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

comment:21 Changed 6 weeks ago by tatsuya46

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:22 Changed 6 weeks ago by tatsuya46

  • Resolution invalid deleted
  • Status changed from closed to reopened

comment:23 Changed 4 weeks ago by tatsuya46

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:24 Changed 4 weeks ago by tatsuya46

  • Resolution invalid deleted
  • Status changed from closed to reopened

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 4 weeks ago by tatsuya46 (previous) (diff)

comment:25 Changed 3 weeks ago by tatsuya46

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 3 weeks ago by tatsuya46 (previous) (diff)

comment:26 Changed 3 weeks ago by tatsuya46

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:27 Changed 3 weeks ago by tatsuya46

  • Resolution invalid deleted
  • Status changed from closed to reopened
Note: See TracTickets for help on using tickets.