Even including Lan? So it will be eth1 and br-lan?
ethtool -K eth1 tso off gso off gro off
ethtool -K br-lan tso off gso off gro off
Or am I understanding wrong?
Well the switch ports do not matter, but the wifi interfaces do as well as the ethernet ports from the SoC to the switch (assuming your router has a switch)
Edited for clarity:
@moeller0, using tc -s qdisc, max_len is 1514. Would you consider that to be ">> 1500" (which I'm guessing means much, much greater than 1500)? I'm using the @cybrnook's stock SQM settings (qdisk is cake, queue setup script is piece_of_cake.qos).
I don't understand your second part. The WRT12/19/32AC(S)(M) series does have an internal switch. So would it need to be applied to all interfaces (eth0, eth1, wifi0, and wifi1)? Eth0 is LAN (output of internal switch to SoC), Eth1 is WAN (connection from WAN port to SoC), wifi0 (connected to SoC) is 5ghz, wifi1 (connected to SoC) is 2.4ghz.
To simply test the command, just run it in SSL.
To make it apply on boot, /etc/init.d/sqm should look like this:
I'm using the package joe as a text editor (needs to be installed). To open the file, simply joe /etc/init.d/sqm. When done editing, press control+KX to save and exit. (or you can any other text editor that you are familiar with)
I'm still waiting to hear back from @moeller0 to see if he recommends adding it for eth1, wifi0, and wifi1 as well. But I have seen a definite improvement (especially with ping) applying it to just eth0 (the WAN port, which is what QoS controls).
As the kernel will keep giants intact once they are built the trick is to make sure the kernel never builds giants in the first place (well, actually cake tries to do the right thing if passed a giant, but it seems something is off there currently). I am uncertain which interfaces actually are able to create giants, so out of caution I will try disable the whole offloading on all real interfaces. In other words: [quote="starcms, post:614, topic:545"]
eth1, wifi0, and wifi1 as well
[/quote]
Now, if testing shows that this does not improve things further from turning off off-loading from the wan interface, I would re-set these other interfaces to their defaults again, with fast links GSO/TSO/GRO are actually good things that help the kernel achieve higher throughput (at high bandwidths giants have only a small latency costs).
Best Regards
Hey @cybrnook
When trying to install @stangri's openvpn-policy-routing, the included packages rep cannot satisfy dependencies, giving installation errors on the following not-included kmods:
kmod-ipt-ipset, kmod-nfnetlink. These are required for ipset installtation (and dnsmasq-full). I think the issue is once you include cryptodev support in the kernel, the kernel version doesn't match the snapshot versions (even though they are both 4.4.52, but the version number after the (dash) is different).
It would be great if you could include these kmods in your build, but I would totally understand if you don't want to!
Also, these kmods are ones I use for my USB-storage and other networking needs:
kmod-fs-hfsplus, kmod-fs-hfs, kmod-sched-connmark,kmod-usb-uhci
I would be totally okay if you'd like to provide me these files to use with the current build instead and you don't feel like releasing a new build.
Thank you!
Uno momento Senior! I will compile a beta build with what should be the dependencies (and your extras). Please test and let me know if the install works after that.
EDIT: @nidstigator Okay, try installting against this one: https://www.dropbox.com/sh/1h8mniose9rtnna/AAAx1Ct2b_MAx4lMXKjH4nboa?dl=0
Hi @cybrnook, that works, thanks!. Are you planning on making one against the stable branch?
Can't trust the 4.9 kernel yet for full-time use.
Sure, just wanted to make sure it worked before moving it to the stable side.
I don't like the fact though that you can't pull from the LEDE/OpenWRT repo's. That was one of my big selling points that I like when moving to a stable branch....... (Need to figure out how to match my kernel signature with the snapshots signature).
On a side note, compiling both new beta and stable now with the changed above (I think the major one for vpn bypass was changing to dnsmasq-full).
New Builds:
r3286-STABLE
r3792-BETA
Added dnsmasq-full and some additional kmods. Should support direct installation of @stangri 's policy based VPN app: VPN Policy-Based Routing + Web UI - ARCHIVE #1
1 Like
Just FYI. I am running davidc502's latest with the 4.9 kernel and it is running flawlessly on my wrt1900acs v1. Been running for 4 days now. Davidc502 builds with the 4.9 kernel do have reboot issues on the wrt1900ac v1. No issues as, I said on, my wrt1900acs v1.
Suspect that cybrnook's will perform fine as well since they are both using the same base code, just minor rev differences.
OK, Just installed cybrnook's latest beta, r3792 with the 4.9 kernel. Installed and came up ok on my wrt1900acs v1. Too early to tell is any issues. Devices are connecting to wireless, etc.
Thanks for adblock being off by default.
Thanks @billmy1228 for testing. I know you always gravitate back to David's builds (you mention it quite a bit 
), but it's still appreciated to hear your feedback.
If you use a VPN, service, check out stangri's policy based app. It seems to be coming along quite well and my builds now have his dependencies. I feel it adds some much needed options to for our users to be able to route only certain things over VPN, instead of whole hog.
And yes, like you mentioned, the code base is the same between all builds. Only thing different is the paint job 
Do you ever test the "stable" branch, or just stick to the beta?
I noticed in the last two builds there is a new radio (radio0, radio1 and radio2), is that right? For WRT3200ACM.
Yes, I believe that has the do with the bluetooth radio that's inside of it. Not sure what it can be used for if anything yet. I think it's there originally for better radar detection.
Thanks buddy
@cybrnook
No I don't normally try the stable builds. I like taking a risk and seeing what is coming down the road. While I have had an issue with some of the beta builds, they normally run just fine for me. I do not use a VPN so have not looked/tested that part of the builds. I know that has been a focus of yours which gives others a good firmware for VPN,
r3286 already, I just flash the old one a few days ago. Thanks again for your hard work.