EA8500
DD-WRT v3.0-r37010M kongat {09/21/18}
Linux 4.9.128 #183 SMP PREEMPT Fri Sep 21 08:40:38 CEST 2018 armv7l
No Reset--GUI install over r36995M
some static leases on main & VLAN clients
local DNS
samba share
ovpn server
VAPs on both radio + one port VLAN via br1
HFSC FQ_CODEL 48kbs/48kbs (21 set in Services Priority) on 50/50 fiber line
Everything working great....Thanks Mr. K this should be a good one
http://www.dslreports.com/speedtest/39220432
Posted: Fri Sep 21, 2018 12:58 Post subject: Re: New (KONG) Build - 09/21/2018 - r37010M
tatsuya46 wrote:
id report but its the exact same thing as all k4.x builds nothings changed..
im guessing the k3.18 builds are forever gone..soon after i was told they wont be gone
I’m proposing Kong help tatsuya take over the k3.18 builds maintenance so he can fully focus on the k4.x
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Fri Sep 21, 2018 13:30 Post subject: Re: New (KONG) Build - 09/21/2018 - r37010M
jerrytouille wrote:
tatsuya46 wrote:
id report but its the exact same thing as all k4.x builds nothings changed..
im guessing the k3.18 builds are forever gone..soon after i was told they wont be gone
I’m proposing Kong help tatsuya take over the k3.18 builds maintenance so he can fully focus on the k4.x
if only i was a developer, let alone a linux one _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
I had really high hope for this build but still pretty bad :/ QoS is all over the place 100Mbps line dropped to 20-90Mbps, dnssec still failed due to isp dns leak.
I had really high hope for this build but still pretty bad :/ QoS is all over the place 100Mbps line dropped to 20-90Mbps, dnssec still failed due to isp dns leak.
I had really high hope for this build but still pretty bad :/ QoS is all over the place 100Mbps line dropped to 20-90Mbps, dnssec still failed due to isp dns leak.
I had really high hope for this build but still pretty bad :/ QoS is all over the place 100Mbps line dropped to 20-90Mbps, dnssec still failed due to isp dns leak.
On the R7800? Are you using HTB + FQ_CODEL?
r7500v2 hfsc + pie
Bulllllshiiiiiit. Do not use hfsc and do not use pie.
Only HTB + FQ_CODEL.
1. HFSC is only useful for slow connections.
2. There is no custom code for PIE in our qos script.
3. CODEL seems to have changed and you will see error messages in console. It is possible, that we have to update tc to be fully compatible with 4.9.
4. I only test with HTB + FQ_CODEL because it performs well in any scenario.
5. Might give cake a little test to see if it is offers anything like reduced cpu load. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Fri Sep 21, 2018 14:57 Post subject:
<Kong> wrote:
jerrytouille wrote:
<Kong> wrote:
jerrytouille wrote:
I had really high hope for this build but still pretty bad :/ QoS is all over the place 100Mbps line dropped to 20-90Mbps, dnssec still failed due to isp dns leak.
On the R7800? Are you using HTB + FQ_CODEL?
r7500v2 hfsc + pie
Do not use hfsc and do not use pie.
Only HTB + FQ_CODEL.
not always true, PIE is certainly better here and gets exact what i enter, fq_codel likes to stay behind what i enter by several megabits, PIE likes to flatline, fq_codel likes to swerve up and down. PIE is less on the cpu than fq_codel is at my throughput. PIE just needs to be coupled with at bare minimum, tcp ack priority checked, but should be all of them (any qos combo can use it really), and a few services (port based, also easier on cpu) entries. it will perform well. i can see why docsis 3.1 chose pie.
cake at least looks like it takes the best out of pie and fq_codel and squishes both together. _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
Posted: Fri Sep 21, 2018 16:59 Post subject: EA-8500
Yes, an absolutely working well build, Well done mr Kong.Qos is working (using Hfsc+pie) and its very good, rapid Web interface ,Samba with decent speeds, cpu is not overloaded,no RX/TX errors yes i will stay om this! Thank you!
Great build but I've figure out the source of my wireless bridge DHCP issues.
If I enable 'multicast_to_unicast=1' to fix the Bonjour issue, my wireless bridge stops handing out IP's. If i revert to 'multicast_to_unicast=0', the bridge works again. Stuck in limbo. _________________ R7800 AP WDS - OpenWrt SNAPSHOT r16941
R7800 Client WDS - OpenWrt SNAPSHOT r16941
R7000 CB - r46949 std
PiHole v5.3.1 - dnscrypt-proxy 2.0.45 - RPi 3 B+
Synology DS220+ - DSM 7 RC
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Fri Sep 21, 2018 19:33 Post subject:
why is a bridge handling dhcp? most would let the host do that..and if its a wireless bridge, is it wds or client bridge? _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
i can see the DHCP server on my pi assigning the correct IPs... but they just dont reach the devices connected to the WUMC710 when I have that multicast setting enabled to 1... the second I turn it off all the devices get their IPs. _________________ R7800 AP WDS - OpenWrt SNAPSHOT r16941
R7800 Client WDS - OpenWrt SNAPSHOT r16941
R7000 CB - r46949 std
PiHole v5.3.1 - dnscrypt-proxy 2.0.45 - RPi 3 B+
Synology DS220+ - DSM 7 RC