yea QCA9980 been on 10.4-3.5.3-00050 long time.....
and the rates were messed for u too, so im guessing there was also a driver change then along with the ct fw (9984) that broke them rather than the ct fw itself.. (same for rekeying wds stations, was also a driver side issue)
No driver change but I added SMPS-STATIC flag, which gives basic power management, still no uapsd. Although ct firmware has also dynamic smps enabled, but didn't work.
I'm back to previous fw, and smps enabled when uapsd is on, will do some more testing, also found a way now to trace full wireless traffic.
To see what's missing.
CT also caused some other issues.
are ur mimo devices returning to mimo operation with smps-static enabled? when i tried it before they rarely returned to mimo but instead stayed at 1x1
EA8500 up little over 5 hrs
all seems to be good
Haven't done a reset for several builds now.
main router
clone WAN MAC
30 static leases
port range forwarding
ovpn server
VLAN on port4 with ath0.1 & ath1.1 via br1
unbound
HFSC & FQ_CODEL
samba share Ext4
I just wish someone would fix the 'using local DNS while connected to its ovpn server' while running unbound ...
...that's been broken for nearly a year now oh well, that's one reason I keep another ovpn server running on a WAP
included tickets are only those affecting r7800 and kong build only.
again nothing really good to report.. wifi latency under load (only 320mbps too, the link is capable of over 200mbps more..) is still a ugly mess and throughput is all over the damn place, up down up down sigh.. fq_codel is wasting upload bandwidth somewhere etc. wifi fq_codel still missing in action (it was here a few months ago and working lovely)
additional wifi issues from 1st version of this build with ct fw appear to be gone.. tried adding ht_capab=[SMPS-STATIC] and wondered why both radios wont come up for a while then noticed it was already on when i saw it in beacon info. [SMPS-DYNAMIC] still wont work.
1 wds station, wndr4300 still seems to be stuck at 1x1 tx rate, r7800 sees it as 450M TX/150M RX. another wds station, dir-862L reports 433M TX/975M RX but mismatches the r7800 wds ap showing 975M TX/866M RX.. but i know BS still hasnt switched ath10k to "proper" tx rate reporting since it was fixed, is instead still using the "expected throughput" formula/hack instead so.. *shrug*..
EDIT: on the dir-862L "expected throughput" value is reported as 433M, tx bitrate reported as 6M, so even if the r7800 wds ap is correct and its really 866M, thats still 2x2 and not 3x3 as r7800 reports the sta is using VHT NSS 2
more testing in the coming hours, might have something to do with rts/cts (according to specs of smps ps) as its disabled on the ap but enabled on wds stas, so far seems like just another r38570m _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
included tickets are only those affecting r7800 and kong build only.
again nothing really good to report.. wifi latency under load (only 320mbps too, the link is capable of over 200mbps more..) is still a ugly mess. fq_codel is wasting upload bandwidth somewhere etc. wifi fq_codel still missing in action (it was here a few months ago and working lovely)
additional wifi issues from 1st version of this build with ct fw appear to be gone.. tried adding ht_capab=[SMPS-STATIC] and wondered why both radios wont come up for a while then noticed it was already on when i saw it in beacon info. [SMPS-DYNAMIC] still wont work.
1 wds station, wndr4300 still seems to be stuck at 1x1 tx rate, r7800 sees it as 450M TX/150M RX. another wds station, dir-862L reports 433M TX/975M RX but mismatches the r7800 wds ap showing 975M TX/866M RX.. but i know BS still hasnt switched ath10k to "proper" tx rate reporting since it was fixed, is instead still using the "expected throughput" formula/hack instead so.. *shrug*..
EDIT: on the dir-862L "expected throughput" value is reported as 433M, tx bitrate reported as 6M, so even if the r7800 wds ap is correct and its really 866M, thats still 2x2 and not 3x3 as r7800 reports the sta is using VHT NSS 2
more testing in the coming hours, might have something to do with rts/cts (according to specs of smps ps) as its disabled on the ap but enabled on wds stas, so far seems like just another r38570m
so far only one thing left to try which is enable rts/cts on the r7800 ap, but so far smps static is not letting wds stations get their tx chains up even when pushing traffic, wndr4300 keeps staying at 1x1 150mbps instead of 3x3 450mbps, dir-862L staying at 2x2 866mbps instead of 3x3 975mbps+. funny cause with those wds stations also on ddwrt, using our messy wifi logic with eachother, ud think they would fair the best.. (like using 80mhz on ch 165+LL LOL invalid but ddwrt will do it with other ddwrt routers).
smps dynamic is what we need (by design, smps static is pretty much working properly..) but it wont work for some reason. id say leave smps static in hostapd as is, but dont auto force it enabled, let the user add it into hostapd conf if desired, or a webif option.
the wds stations are running without smps static cause well BS doesnt really seem to care about much, so they dont work there.. be interesting to see the results with sta + ap both with it enabled. _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Thu Feb 14, 2019 16:18 Post subject:
i think dnsmasq just did a back to back crash...
more OOM bullshit when the router has the usual over 57% free ram.. only currently at 630,000/1,000,000 lines of ad/trackblocking that dnsmasq was tested for.
oh well, that's one reason I keep another ovpn server running on a WAP 
only currently at 630,000/1,000,000 lines of ad/trackblocking that dnsmasq was tested for.