Thank you @hnyman!
I am now back on the stable version, everything is working great, as before.
Too bad OpenVPN's "comp_lzo" option is not working properly, so I cannot use the Master as I need OpenVPN's client to work.
Hi, what doesn't work? For me comp_lzo working on latest master without any problem.
On the server side: option compress lzo
On the client side: comp-lzo yes
I got a bit further but not by much.
I did manage to get a IPv6 on the WAN6 interface but no prefix delegation. Also, I can't seem to access anything in ipv6, if I try to ping6 google from the router sometimes I get a reply other times I don't and my PCs only get link-local addresses.
My IPv6 WAN status looks like this:
I have comp_lzo configured in VPN Client on LEDE (I've tried one by one configuration with no, yes, and adaptive), but in the logs it says that the VPNServer is configured with comp_lzo and is asking for it, while Lede is reporting that the option is not configured on the client - even if I can see it in the confg file.
And in the Ledel log is calling it "comp-lzo", while in the configs I see as "comp_lzo". Maybe some syntax mismatch?
Something like this:
WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
Again: I do have the option configured in the OpenVPN client in Lede.
You might ask that VPN stuff in a separate thread in the network section of the forum, so that VPN specialists notice it. They don't probably read this build-specific thread, so your question does not get attention...
I've been here a while back but sort of stopped following because at the moment many changes were taking place. Now it seems lots have moved on. Im currently on a stable release from about 8-12 months ago. I have gigabit internet and my WAN-to-LAN speeds are very close to max speeds (about 800-900 mbps) and I can push 5GHz radio to about 550mbps.
I want to know if there has been significant changes that will improve the performance further.
Does the added benefit of fast-path make any difference ?
One of my issues is that I have a variable ping latency which I never had with the ath9k based openwrt routers. For instance my ping would be constantly between 4-5 ms when running speedtest via the buffalo WZR600 router. On the netgear I can never see 4 ms, it is usually between 8-9 ms., which is honestly double what I saw in the buffalo.
Any advice?
I looked at the gitlog for @hnyman's latest stable branch build, but I couldn't find anything related to ath10k LEDs and the latency fixes as described in this thread.
@hnyman, does stable—in particular, lede1701-r3877-23a638ebd1-20180425—have both working LED patch and latency fix? I'm a bit wary of master branch, since I had an issue with nlbwmon using near 100% CPU utilization for over 16 hours at one point. It hasn't occurred on stable, which is why I prefer stable at the moment.
I keep the changes uncommitted, so they are not in any git log.
You can see the made changes in the patch files that are available with each firmwares download directory. The LED fix is quite visible in ...main.patch
Stable contains the wifi LED fix, but not the latency fix. Latency fix is mostly needed for the extra management stuff introduced after 17.01 had already branched.
However, based onath10k mailing list discusison, the problem may the relate to the whole firmware 3.5.3 series. In any case, the underlying issue seems to be discussed and fixed in the ath10k list: http://lists.infradead.org/pipermail/ath10k/2018-April/011335.html
I am not using VHT160 myself, so no idea about the bug.
The newest master build contains soft-brick protection for LuCI from @jow
In case the user makes a config change via LuCI that breaks connectivity from PC to the router, the router automatically rolls back to the old config (and then warns the user about the impact and offers the possibility to forcibly apply the config despite the impact).
This should prevent accidental connectivity losses e.g. via firewall changes, wifi SSID changes, router IP changes, VLAN changes etc.as long as those changes are made via LuCI.
hello,
updated to r3879, all good.
I see the TX power has gone down to a normal 20dBm on 2.4G (it was 30 on previous), but i still can't understand if it's normal that the system is always transmitting at the maximum power when it's set to AUTO..
rock solid, very nice build, thank you
Changes to the SQM settings are not activated by LUCI in build 6781. After "save and apply" there is a message "No changes to apply" for about one second and a speed test remains the same. A /etc/init.d/sqm restart does the trick. I suspect a bug in LUCI here, maybe not only for hnymans build but I can't confirm this.
Anyone seeing this also?
BTW I'm stuck at about 150 Mbps download with cake and piece_of_cake with either a 200 and 400 Mpbs line via cable. Without SQM download is 425 Mbps and almost that with fq_codel and simplest.qos while getting bufferbloat and reasonable higher pings respectively. piece_of_cake still gives the best pings while under full download.
Despite the message "Configuration successfully applied" still no change seen with tc -s qdisc show dev eth0 between cake and fq_codel in 6781. I will observe this. Maybe other options in LUCI are affected also...
In addition to the experimental rollback code now in my buils, there has also been other changes in LuCI core logic recently, so it might be that some functionality has got broken, or at least some LuCI apps are now misbehaving.
I just tested and
with plain r6755 (without LuCI rollback) both SQM and luci_statistics config changes kicked off a process restart
with r6787+rollback the process restart does not happen