CakeQOS cake not working with AX58U on 386.1

[jata]

Just did a new clean install of 386.1 (b5) on AX58U and installing cake-qos totally kills the internet/wan. Only way to restore internet is to uninstall cake.

Had the same issue on b3 but thought I would try again with b5. Also tried my spare AX58U but exactly same issue after full/new/clean install including new USB/swap/entware etc

Does anyone have AX58U + 386.1 + cake working?

 

[underdose]

Does anyone have AX58U + 386.1 + cake working?

I don't believe so.

AX58U No Internet · Issue #66 · ttgapers/cakeqos-merlin

Install AX58U via Entware works When enabling Cake-QOS, all internet traffic is stopped. LAN traffic works. Any setting within Cake-QOS, no go. No error message found in system logs. To re-enable i...

github.com

 

[HearToLearn]

Does the sch_cake.ko file exist?

config file: vi /jffs/addons/cake-qos/cake-qos
default location: /opt/lib/modules/sch_cake.ko
cmd to find file: find / -name "sch_cake.ko"

 

[ttgapers]

Thanks for the notes everyone. I've collapsed the open issues in Git to the main issue related to AX58U and Internet access as they do not use eth0 (as most other Asus routers) for their WAN but rather eth4. We are aware of it and will get around to correcting it. @Adamm and @dave14305 are both involved in the issue.

For details see: https://github.com/ttgapers/cakeqos-merlin/issues/60

I find it easier to track Issues there. I've also enabled the Discussions area in Git as a PoC/Pilot for keeping Cake-QoS related items in one place rather than scattered threads.

Cheers.

 

[dave14305]

I would be surprised if it’s a script issue because unless there’s Dual-WAN or PPP connection involved, it should work just fine with nvram get wan0_ifname to determine the interface.

Output from tc qdisc ls and the nvram command above would help understand if anything changed.

 

[ttgapers]

I would be surprised if it’s a script issue because unless there’s Dual-WAN or PPP connection involved, it should work just fine with nvram get wan0_ifname to determine the interface.

Output from tc qdisc ls and the nvram command above would help understand if anything changed.

Same is what I am thinking as well, else we would probably have more reported issues around the AX58U. @jata care to assist, as I don't have a device to test with.

Cheers

 

[underdose]

I would be surprised if it’s a script issue because unless there’s Dual-WAN or PPP connection involved, it should work just fine with nvram get wan0_ifname to determine the interface.

Output from tc qdisc ls and the nvram command above would help understand if anything changed.

wan0_ifname is eth4, tc qdisc ls is below but before you dive in I have to warn you I don't have CakeQoS installed for the obvious reasons (no WAN), instead I have FlexQoS so I'm not sure if the output below is helpful or not.

qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth2 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth3 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc htb 1: dev eth4 root refcnt 2 r2q 10 default 0 direct_packets_stat 5023009 direct_qlen 1000
qdisc fq_codel 8015: dev eth4 parent 1:2 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8017: dev eth4 parent 1:10 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8019: dev eth4 parent 1:11 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801b: dev eth4 parent 1:12 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801d: dev eth4 parent 1:13 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801f: dev eth4 parent 1:14 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8021: dev eth4 parent 1:15 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8023: dev eth4 parent 1:16 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8025: dev eth4 parent 1:17 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc pfifo_fast 0: dev eth5 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth6 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc htb 1: dev br0 root refcnt 2 r2q 10 default 0 direct_packets_stat 8862009 direct_qlen 2
qdisc fq_codel 8014: dev br0 parent 1:2 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8016: dev br0 parent 1:10 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8018: dev br0 parent 1:11 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801a: dev br0 parent 1:12 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801c: dev br0 parent 1:13 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801e: dev br0 parent 1:14 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8020: dev br0 parent 1:15 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8022: dev br0 parent 1:16 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8024: dev br0 parent 1:17 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn

 

[ttgapers]

wan0_ifname is eth4, tc qdisc ls is below but before you dive in I have to warn you I don't have CakeQoS installed for the obvious reasons (no WAN), instead I have FlexQoS so I'm not sure if the output below is helpful or not.

qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth2 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth3 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc htb 1: dev eth4 root refcnt 2 r2q 10 default 0 direct_packets_stat 5023009 direct_qlen 1000
qdisc fq_codel 8015: dev eth4 parent 1:2 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8017: dev eth4 parent 1:10 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8019: dev eth4 parent 1:11 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801b: dev eth4 parent 1:12 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801d: dev eth4 parent 1:13 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801f: dev eth4 parent 1:14 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8021: dev eth4 parent 1:15 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8023: dev eth4 parent 1:16 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8025: dev eth4 parent 1:17 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc pfifo_fast 0: dev eth5 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth6 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc htb 1: dev br0 root refcnt 2 r2q 10 default 0 direct_packets_stat 8862009 direct_qlen 2
qdisc fq_codel 8014: dev br0 parent 1:2 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8016: dev br0 parent 1:10 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8018: dev br0 parent 1:11 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801a: dev br0 parent 1:12 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801c: dev br0 parent 1:13 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801e: dev br0 parent 1:14 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8020: dev br0 parent 1:15 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8022: dev br0 parent 1:16 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8024: dev br0 parent 1:17 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn

Not so much but it shows you are using eth4. You would need some spare time to remove, reboot and reinstall cake if you would like to test further. Other users do not seem to be having the issue you are experiencing. But this is Beta Merlin you are running correct? If so, if @jata is also experiencing the issue on the latest Beta firmware (which doesn't exist on the latest stable) I would suggest rolling back to stable and re-installing.

I haven't had the chance to load the latest betas for various reasons (another project going through a major update for example), but will gear back down here shortly, once the latest betas stabilize

Cheers

 

[Tekneek]

386.1 was released today. I installed it and experienced the same problem w/ my RT-AX3000 (basically RT-AX58U) as was reported by the original poster.

I had to remove cake-qos and reboot to pass Internet traffic.

I can try to help w/ testing this weekend.

 

[Tekneek]

I am running without any kind of QOS at the moment. Here is the output of tcqdisc ls and nvram get wan0_iframe:

# tc qdisc ls
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth2 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth3 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth4 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth5 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth6 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wl0.1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wl0.2 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wl1.1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wl1.2 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

# nvram get wan0_ifname


eth4

 

[dave14305]

At this point I would guess that cake and tc-adv need to be recompiled against 386.1 because Asus modified rtnetlink in the kernel. I could be very wrong, but not sure what else explains the sudden breakage.

 

[jata]

Thanks for all the input/help with this issue.

I have reverted to 384.19 for my entire network. However, I do have 2x AX58Us in my setup (one is a node) so I can take this off my main/prod network and do some testing to help with this issue over the next few weeks if helpful.

as per @ttgapers request - I will monitor and assist via the github issue/thread.

 

[jata]

At this point I would guess that cake and tc-adv need to be recompiled against 386.1 because Asus modified rtnetlink in the kernel. I could be very wrong, but not sure what else explains the sudden breakage.

Coming back to this topic because I really want to get cake working on my RT-AX58U based 386.1 network (sorry @ttgapers)...

Do we know if this issue requires cake to be recompiled? And who/how do we do this?

I'm happy to help but my compiling skills are not great (none) but I am a quick learner

 

[underdose]

Coming back to this topic because I really want to get cake working on my RT-AX58U based 386.1 network (sorry @ttgapers)...

Do we know if this issue requires cake to be recompiled? And who/how do we do this?

I'm happy to help but my compiling skills are not great (none) but I am a quick learner

You don't need to compile anything, here's a working fork of cake-qos for AX58U: https://github.com/underd0se/cakeqos-merlin

 

[jata]

You don't need to compile anything, here's a working fork of cake-qos for AX58U: https://github.com/underd0se/cakeqos-merlin

That's great. Thanks @underdose

What did you need to change to get it working?

Testing today and will report back...

 

[jata]

cake now installed and working on my AX58U 386.1 network. So far my experience is:

1. buffer bloat massively improved from B-C to A
2. download speed massively reduced (from 55mbps to <30mbps)
3. cake on 384 with exact same settings was 45mbps with consistent A or A+

Any thoughts on why dl speed reduced so much on 386?

 

[jata]

happy with this from latest test (changed my dl speed from 50 to 47 all good)

thanks again @underdose

 

[underdose]

That's great. Thanks @underdose

What did you need to change to get it working?

Testing today and will report back...

All I did was replacing the binaries with the newer ones from Odkrys' repo, updating versions.txt with the new file versions and I believe that was it.

 

[Kingp1n]

happy with this from latest test (changed my dl speed from 50 to 47 all good)

thanks again @underdose

View attachment 31290

What are your settings under the optional setting?

 

[slidermike]

Team, I just installed cake-qos on my rt-ax86u running 386.1_2
Charter (Docsis)
450Mbps | 20Mbps
spdMerlin confirms I am getting the expected bandwidth consistently.

With Cake-qos enabled and configured for docsis
I am getting downloads in the 220Mbps range.
Cake has helped my dslreports score in regards to buffer bloat.

I understand that at this time ax86u support is experimental. (Appears to function for me - at least initially).
I am also aware that ttgapers says cake is not recommended for bandwidth over 250Mbps or higher.

When monitoring the router gui
I find that cake-qos is ONLY using core 1.
During speed testing, cpu 1 is hitting near 90% while the other 3 are at or near 1%.

Is there a switch or other method to enable multi-core support for cake-qos currently?
If it is currently cpu bound then unlocking all 4 cores would be a big help.
Or perhaps validating the power saving is off (max-speed) if this has a limit otherwise not easily bypassed.
Or moving the ingress (or egress) shaper instance to an alternate core.

These are my currently set parameters in cake-qos
[1] --> Download Speed | [450 Mbit]
[2] --> Upload Speed | [20 Mbit]
[3] --> Queue Priority | [besteffort]
[4] --> Extra Download Options | [docsis]
[5] --> Extra Upload Options | [docsis ack-filter]

Spoiler: tc -s qdisc show dev eth0

v125027@AX86U:/tmp/home/root# tc -s qdisc show dev eth0
qdisc cake 8011: root refcnt 2 bandwidth 20Mbit besteffort triple-isolate nat nowash ack-filter split-gso rtt 100.0ms noatm overhead 18 mpu 64 no-sce
Sent 171389617 bytes 484143 pkt (dropped 4416, overlimits 539478 requeues 0)
backlog 0b 0p requeues 0
memory used: 240Kb of 4Mb
capacity estimate: 20Mbit
min/max network layer size: 28 / 1500
min/max overhead-adjusted size: 64 / 1518
average network hdr offset: 14

Tin 0
thresh 20Mbit
target 5.0ms
interval 100.0ms
pk_delay 521us
av_delay 71us
sp_delay 3us
backlog 0b
pkts 488559
bytes 172379927
way_inds 1704
way_miss 1010
way_cols 0
marks 0
drops 427
ack_drop 3989
sp_flows 2
bk_flows 1
un_flows 0
max_len 1514
quantum 610

qdisc ingress ffff: parent ffff:fff1 ----------------
Sent 1500944943 bytes 1117584 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
v125027@AX86U:/tmp/home/root#