I believe it is https://github.com/lede-project/source/pull/1269, @xirus/@dissent1 feel free to correct me if otherwise.
1 Like
Can you make 'max stripped down dumb AP version'? Possibly with updated hostapd to latest source?
Just flashed latest release and I'm getting a lot of repeated messages in dmesg:
[ 17.672295] nf_conntrack version 0.5.0 (1963 buckets, 7852 max)
[ 17.855106] qca_ssdk: Unknown symbol ppp_hold_channels (err 0)
[ 17.861293] qca_ssdk: Unknown symbol ppp_release_channels (err 0)
[ 17.867618] qca_ssdk: Unknown symbol ppp_channel_get_protocol (err 0)
[ 17.874279] qca_ssdk: Unknown symbol ppp_is_multilink (err 0)
[ 17.942804] qca_ssdk: Unknown symbol ppp_hold_channels (err 0)
[ 17.948994] qca_ssdk: Unknown symbol ppp_release_channels (err 0)
[ 17.955320] qca_ssdk: Unknown symbol ppp_channel_get_protocol (err 0)
[ 17.961984] qca_ssdk: Unknown symbol ppp_is_multilink (err 0)
[ 18.015345] qca_ssdk: Unknown symbol ppp_hold_channels (err 0)
[ 18.021526] qca_ssdk: Unknown symbol ppp_release_channels (err 0)
[ 18.027853] qca_ssdk: Unknown symbol ppp_channel_get_protocol (err 0)
[ 18.034510] qca_ssdk: Unknown symbol ppp_is_multilink (err 0)
[ 18.072397] tun: Universal TUN/TAP device driver, 1.6
[ 18.077583] tun: (C) 1999-2004 Max Krasnyansky maxk@qualcomm.com
[ 18.124652] qca_ssdk: Unknown symbol ppp_hold_channels (err 0)
[ 18.130837] qca_ssdk: Unknown symbol ppp_release_channels (err 0)
[ 18.137165] qca_ssdk: Unknown symbol ppp_channel_get_protocol (err 0)
[ 18.143824] qca_ssdk: Unknown symbol ppp_is_multilink (err 0)
[ 18.218591] qca_ssdk: Unknown symbol ppp_hold_channels (err 0)
[ 18.224792] qca_ssdk: Unknown symbol ppp_release_channels (err 0)
[ 18.231138] qca_ssdk: Unknown symbol ppp_channel_get_protocol (err 0)
[ 18.237802] qca_ssdk: Unknown symbol ppp_is_multilink (err 0)
[ 18.289300] qca_ssdk: Unknown symbol ppp_hold_channels (err 0)
[ 18.295493] qca_ssdk: Unknown symbol ppp_release_channels (err 0)
[ 18.301821] qca_ssdk: Unknown symbol ppp_channel_get_protocol (err 0)
[ 18.308485] qca_ssdk: Unknown symbol ppp_is_multilink (err 0)
[ 18.370723] qca_ssdk: Unknown symbol ppp_hold_channels (err 0)
[ 18.376927] qca_ssdk: Unknown symbol ppp_release_channels (err 0)
[ 18.383273] qca_ssdk: Unknown symbol ppp_channel_get_protocol (err 0)
[ 18.389937] qca_ssdk: Unknown symbol ppp_is_multilink (err 0)
[ 18.459072] qca_ssdk: Unknown symbol ppp_hold_channels (err 0)
[ 18.465255] qca_ssdk: Unknown symbol ppp_release_channels (err 0)
[ 18.471586] qca_ssdk: Unknown symbol ppp_channel_get_protocol (err 0)
[ 18.478244] qca_ssdk: Unknown symbol ppp_is_multilink (err 0)
The only reference I found is here: Hardware NAT For LEDE - #12 by gwlim and the previous two entries, but looking at the @gwlim GitHub I found that the patch is in the "broken" folder.
Is there a technical reason why this build (and trunk nightlies) haven't yet been updated to 4.9 kernel?
No, sorry. You can use this version as AP and I'll keep using whatever hostapd versions the LEDE upstream provides.
I'm just using gwlim's port and he's getting the same errors apparently, see Hardware NAT For LEDE .. It doesn't matter anyway, since we can't use hwnat yet because we don't know the commands. Also it isn't really needed anymore with fastpath. So I might remove this altogether.
If you're referring to this patch - I'm not using it.
@glim's patches are for 4.4 and the LEDE upstream hasn't switched to 4.9 yet either. Because apart from optimizations I try to stay as close to the upstream code as possible, I won't upgrade to 4.9 until they do.
Can anyone test the C7 performance after I manual patch stable to receive the latest ath10k firmware from trunk?
Please make sure you have a high end client adapter to negotiate high throughput rate
It seems that trunk's wireless ac throughput is higher than stable, am I right or wrong, I don't have Wireless AC hardware to test so I don't know, please test and let me know.
The wireless difference between stable and trunk is simply the firmware version, hostapd is the same.
Also I pushed memset and memcpy musl optimization patches so operations involving memset and memcpy functions should be faster.
I already tested it > 1 week stable on my mips24k and mip74k and mpc8548.
Where is this firmware you talking about for testing?
Thanks again and welcome back! DNS doesn´t work or was disabled under /etc/config/dhcp
-> **#**option resolvfile '/tmp/resolv.conf.auto'
I can check with some new ThinkPad´s next week - please PM and I´ll test.
@all
What Interface should I use for SQM ? It´s not really clear in that case.... (compared to a wndr3700v2 
)
This is intentional - with this config it uses dnscrypt-proxy instead of a "normal" resolver. If you have issues resolving domain names, please just restart dnscrypt-proxy service and it will work.
1 Like
To fix the dnscrypt service start which symtoms often include no internet with the error msg in chrome/webbrowsers about DNS_PROBE_FINISHED_NO_INTERNET
- Login with ssh
- Open /etc/rc.local with text editor (vi/nano/etc)
- copy and paste this above exit 0
sleep 10
/etc/init.d/dnscrypt-proxy start
The dnscrypt service doesn't seem to wait until the interfaces are up, thus causing problems on reboots/crashes/dns issues. This script just makes it wait 10 seconds before starting it, a simple workaround. I hope you impliment these changes into the next build. As of writting the 2017-08-03 build still has these issues.
Original source: https://wiki.openwrt.org/inbox/dnscrypt
1 Like
FYI, the eth0.3 trick worked to fix the bootloops caused by IPv6 back in April.
I just installed the latest build, changed wan6 back to eth0.2 and can confirm that the bootloop issue has been fixed (probably somewhere in upstream). IPv6 now works perfectly.
1 Like
Wifi is faster (close to TP-Link original firmware). And Luci is much slower.
Strange errors on system log.
That's because I re-added option mtu_fix 1 to /etc/config/firewall. The lack of that was what was actually causing the problem - just took us a while to figure out.
The errors can be ignored (I'll likely remove what's causing them soon - they're nothing that would affect you) and you could switch to the LuCI default theme to see if that works better for you.
Thanks. Will ignore the error. I've rebooted but Luci slowness is still there. I didn't change the theme previously (July 2nd? build) and now it's much slower but I'll bear with it since I don't plan to do changes often. Memory usage is higher. I've 50% left previously, now is 45%. I have two Archer with same build, etc. So it's easier to compare.
Could the slowness come from https/ssl being enabled by default?
I always assumed that the lag had to do with the slower CPU in the router struggling to keep up with the SSL handshake.
Not sure. It appears that every "page" I try to access on Luci takes a while to load, almost like it's trying to resolve URL or something. I know that the router has single core and slower CPU but the CPU load is maybe 1-2% at most. Nothing has changed in my config except the firmware and this is the same on both my Archer C7. I did a quick measurements, Average 5 to 10 seconds per page load. I didn't measure this previously. I would assure the delay is due to Luci taking longer when "talking" to the other components to grab the info and not just SSL...
I pushed memcpy, memset MIPS assembler optimization for musl as well as updated ath10k firmware from truck.
Wireless performance should be on parity as Trunk.
2 Likes
@r00t - It looks like SQM ingress support with Fast Path with this patch works: Qualcomm Fast Path For LEDE
So, this is kind of weird since
(1) I'm replying to myself.
(2) The problem with LUCI being slow , disappear after 1 day and it's pretty responsive although I have not made any chances to the configuration. It's averaging 1-2 seconds or less. Usually less. Other than the previous reboot, I have not made another one since and there has been no change in my configurations. So it's curious as to why this would be so ?