Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Thu Nov 15, 2018 6:46 Post subject:
mrjcd wrote:
tatsuya46 wrote:
https://github.com/kvalo/ath10k-firmware
new firmwares for qca9880 & 9984
Yea well wonder what the hecks going on with 9980 --- it has been on ath10k firmware ver 10.4-3.5.3-00050 for long long time.
looks like qca dropped it in favor of qca9984, when the only(?) difference is vht160 & 80+80 support... (which only operates in 2x2 mode anyway, somewhat pointless)..
companies are known for their logic now a days _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
I am trying to summarise a sense of how well this router works with DD-WRT. I am looking to replace a WNDR3800v2 which has been running since ages.
I've tried jumping aboard a broadcom router; however with the VLAN / VAP issues I have yet been able to deploy a working version of it. It's collecting dust.
I am seeing discussions about latency issues in this thread. Will this be an issue if jumping aboard this router? I will not be using / implementing QoS. I will be using bridge interfaces to L2 connect VLANs on the switch to individual VAPs with different encryption standards.
I would appreciate if someone using this router could kindly summarise what the major issues are and under what features they would be affected. Thanks a bunch
in that case, ya u will have latency issues.. the internet without qos is filthy with lag written all over it..
in the other way u mean it, no, local latency without qos is <1ms especially with ethernet.
Unless someone is actively DDOS:ing me I believe that I should be perfectly fine with internet traffic. 10Gbit/s fiber uplink to my ISP.
The device itself will receive a full 1Gbit/s with matching Internet connectivity. Pretty much dedicated to itself. No other ports on the device will be used. Just one port with 4 VLANs L2 connected to VAPs. Rest of my wired connections go via my main switch.
I think the WiFi bands will be saturated way before the uplink gigabit port. However; as the performance of wifi is so undeterministic by nature I would not be able to set any good QoS limits anyhow.
My takeaway from your response is that it should work perfectly fine as intended then. Thanks.
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Thu Nov 29, 2018 12:38 Post subject:
mha wrote:
tatsuya46 wrote:
mha wrote:
I will not be using / implementing QoS.
in that case, ya u will have latency issues.. the internet without qos is filthy with lag written all over it..
in the other way u mean it, no, local latency without qos is <1ms especially with ethernet.
Unless someone is actively DDOS:ing me I believe that I should be perfectly fine with internet traffic. 10Gbit/s fiber uplink to my ISP.
The device itself will receive a full 1Gbit/s with matching Internet connectivity. Pretty much dedicated to itself. No other ports on the device will be used. Just one port with 4 VLANs L2 connected to VAPs. Rest of my wired connections go via my main switch.
I think the WiFi bands will be saturated way before the uplink gigabit port. However; as the performance of wifi is so undeterministic by nature I would not be able to set any good QoS limits anyhow.
My takeaway from your response is that it should work perfectly fine as intended then. Thanks.
the wifi driver in use has fq_codel in it, so when it saturates it SHOULD not have that horrible near 1000ms bufferbloat on it like we had since forever, i get about +20ms on a saturated 80mhz 2x2 link _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
Unless someone is actively DDOS:ing me I believe that I should be perfectly fine with internet traffic. 10Gbit/s fiber uplink to my ISP.
The device itself will receive a full 1Gbit/s with matching Internet connectivity. Pretty much dedicated to itself. No other ports on the device will be used. Just one port with 4 VLANs L2 connected to VAPs. Rest of my wired connections go via my main switch.
I think the WiFi bands will be saturated way before the uplink gigabit port. However; as the performance of wifi is so undeterministic by nature I would not be able to set any good QoS limits anyhow.
My takeaway from your response is that it should work perfectly fine as intended then. Thanks.
the wifi driver in use has fq_codel in it, so when it saturates it SHOULD not have that horrible near 1000ms bufferbloat on it like we had since forever, i get about +20ms on a saturated 80mhz 2x2 link
That's very cool! I'll have to try it out! Ordered the device. Let's see how it rolls.
You can do that but it is not advisable because of the limited write cycles on the internal flash it can become stuffed.
You use the parameter -g to set the transmission daemon config files path and you can set the path for downloads inside the transmission config json file.
You can do that but it is not advisable because of the limited write cycles on the internal flash it can become stuffed.
You use the parameter -g to set the transmission daemon config files path and you can set the path for downloads inside the transmission config json file.
You can do that but it is not advisable because of the limited write cycles on the internal flash it can become stuffed.
You use the parameter -g to set the transmission daemon config files path and you can set the path for downloads inside the transmission config json file.
Yes but it won’t be regular writings, right? It is one-time action when I setup configuration
Also, in general which repo is better to use?
Kong’s repo, optware, entware or maybe Voxel’s repo? Are they adopted somehow to particular r7800 model?
Compared to other repos, my repo is built with the exact same toolchain as the firmware is built, there is one patch in our toolchain that is incompatible with other toolchains, apps that use this standard structure will fail, as mem layout is different.
I also use crypto signature to make sure you don't pull in manipulated packages in case someone hacks the hosting server. I'm not aware that the other projects check any crypto signature.
The way I compile all of my builds make it possible to use the repo with different socs. BS often uses different flags, that may give a few percent additional performance but they usually break optware, e.g. if you mix soft/hardfloat
Posted: Wed Dec 05, 2018 8:17 Post subject: Problem with IPcam on the newest build
I got a problem with one of my two WIFI IPcams after i just upgraded from build r37120 to r37900.
There was no problem before but now the IPcam try to connect 3 times before it stops. The other IPcam of the same brand and model has no problem and connect instantaneous. I get this in syslog every time it tries:
Dec 5 09:05:11 DD-WRT daemon.info hostapd: ath1: STA xx:xx:xx:xx:xx:xx IEEE 802.11: deauthenticated due to local deauth request
Edit: Never mind was just because the channel selection was changed. BTW does the newer builds have problems selecting the most optimal channel in crowded space?
EDIT: Found all the answers _________________ Active devices:
Netgear R7800 - Stock v1.0.2.68
Linksys EA8500 - OpenWRT 19.07.1
ASUS RP-AC68U - 3.0.0.4.382.40019
Ordered the device. Let's see how it rolls.