What's new

[Alpha] 386.2

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
You should soon be able to have it, and eat it. /cryptic wizard hat off
That's so funny. I always wondered these last 1 1/2 years what your pic of the |> represented. It's a wizard hat on its side, OF COURSE! :D
 
Also just to keep everyone's expectations at a reasonable level: this is not compatible with hardware acceleration. So, forget about using Cake on your 500 Mbps connection, your CPU won't be able to keep up.
Correct as is the case with the addon now :)
 
The question is: Will you have to uninstall independent script prior to firmware upgrade?
Do the settings port?

These are all early days still - and thinking about the logic for it -- assuming we work out the hows, on implementing any customization to what comes from Merlin OOTB. In short yes, I/we would prefer it this way as well, but a bit too early to absolutely sure.
 
I hope Merlin is going to wait and base the next round of Alphas and Beta's on newer GPL code besides 41700. Assuming Asus is done playing there New Year games 3 months after it happened. :oops:
 
If cake is coming to the webui, is there a chance of enabling skbedit so we can apply our own DSCP marking as well then?
This should already work (the DSCP netfilter target is already available):

Code:
iptables -t mangle -A FORWARD -p tcp --dport 8888 -j DSCP --set-dscp 1
 
Here`s a preview of the UI (I wanted to keep it simple, so only the fields related to overhead are available, and there is a preset dropdown to prefill them, just like with fq_codel:

View attachment 31455

Setting Bandwidth to "0" or "Automatic" will configure cake with bandwidth set to "unlimited". ingress-autorate was tested, and it was totally useless. Connecting to the router's WAN interface over SSH or the webui was ridiculously slow.
@RMerlin, has alot change from using current cake-qos script compared to GUI built-in cake option? I saw this so I'm guessing the upstream is now differsev3 and besteffort on upstream compared to current script which the default was set to besterffort.

Thanks for baking cake into the GUI. Awesome job!!!

Code:
rc: implement Cake QoS mode for HND routers

Cake support is implemented as new qos_type of 9 (high
number was used to avoid conflicts in case Asus add more
qos types in the future).  A couple of notes:

- Only supported by kernel 4.1.xx (that's HND models at this time)
- Not compatible with flow cache/runner/archer acceleration,
  so currently not suitable for connections above ~350 Mbps
- In line with the original Cake design philosophy, only a limited
  number of configurable settings are exposed to the user
- If user sets bandwidth to Automatic (or 0) on webui, then set
  bandwidth to unlimited.  ingress-autorate was tested, and
  show to provide very poor performance, so it wasn't implemented
- A diffserv3 setup is used for upstream (so users of ATA/VoIP
  phones with diffserv support can benefit from it), and
  besteffort on downstream
- overhead (including mpu, atm and ptm settings) are supported
  at the webui level
- nat mode is enabled if the router handles NAT
 
This should already work (the DSCP netfilter target is already available):

Code:
iptables -t mangle -A FORWARD -p tcp --dport 8888 -j DSCP --set-dscp 1
My understanding was that this was for egress only. Doesn't "tc filter" need to be used for ingress tagging?
 
So in theory my 100/40 VDSL 2 connection should be fine with cake, and also is this a a part of adaptive QoS or seperate like traditional QoS?
 
So in theory my 100/40 VDSL 2 connection should be fine with cake, and also is this a a part of adaptive QoS or seperate like traditional QoS?
It's separate.
Which does raise a good point. Hopefully the GUI is accessible without needing to enable the global QoS slider, and hence needing to give permissions for Trend Micro. I definitely prefer having Trend Micro entirely off with permissions withdrawn.
 
That's so funny. I always wondered these last 1 1/2 years what your pic of the |> represented. It's a wizard hat on its side, OF COURSE! :D
Hmmm...I seem to recall the Icelandic language has a letter like that, and it's pronounced TH as in Thor, who swings a mighty mjolnir. <shrug>
 
Which does raise a good point. Hopefully the GUI is accessible without needing to enable the global QoS slider, and hence needing to give permissions for Trend Micro. I definitely prefer having Trend Micro entirely off with permissions withdrawn.

Good question. I am testing right now and although I did have to enable the slider, the option for "Withdraw" on the Admin>Privacy tab is still not available (similar to my routers with the addon only).....
 
Good question. I am testing right now and although I did have to enable the slider, the option for "Withdraw" on the Admin>Privacy tab is still not available (similar to my routers with the addon only).....
Oh ok, sounds like it might be safe to do then. Perhaps my mistake in thinking that slider would trigger the permissions. Must also need to enable adaptive to trigger the permissions prompt.
 
My understanding was that this was for egress only. Doesn't "tc filter" need to be used for ingress tagging?
No idea, I never played with that. I just saw a reference to using the DSCP target in a Cake-related thread through a quick Google search.

Oh ok, sounds like it might be safe to do then. Perhaps my mistake in thinking that slider would trigger the permissions. Must also need to enable adaptive to trigger the permissions prompt.

Only Adaptive QoS requires the Trend Micro engine. None of the other QoS modes do.
 
@RMerlin, has alot change from using current cake-qos script compared to GUI built-in cake option? I saw this so I'm guessing the upstream is now differsev3 and besteffort on upstream compared to current script which the default was set to besterffort.
I loosely based my design on Lede/OpenWRT scripts such layer_cake, not on CakeQOS. I'm going with diffserv3 on the upstream because most VoIP solutions will use DSCP out of the box (both my work VoIP phone and my home ATA do). This will allow improved VoIP handling, which is more important IMHO than just trying to get the nicest latency charts off test sites.

This is an example of a QoS script generated by the firmware on my test setup at this time in development (things are still in flux and are not final):

Code:
#!/bin/sh
ULIF='eth0'
DLIF='eth0'
MIF='ifb4eth0'
ULBW='bandwidth 51200kbit'
DLBW='bandwidth 409600kbit'
OVERHEAD='overhead 38 mpu 84'
FRAMING=''

case "$1" in
start)
# Upload
        tc qdisc add dev $ULIF root cake nat diffserv3 $ULBW $OVERHEAD $FRAMING 2>/dev/null

# Download
        ip link add name $MIF type ifb 2>/dev/null
        tc qdisc add dev $DLIF handle ffff: ingress 2>/dev/null
        tc qdisc add dev $MIF root cake nat wash $DLBW besteffort $OVERHEAD $FRAMING 2>/dev/null
        ip link set $MIF up 2>/dev/null
        tc filter add dev $DLIF parent ffff: prio 10 matchall action mirred egress redirect dev $MIF 2>/dev/null

        ;;
stop)
        tc qdisc del dev $ULIF root 2>/dev/null
        tc qdisc del dev $DLIF ingress 2>/dev/null
        tc qdisc del dev $MIF root 2>/dev/null
        ip link set $MIF down 2>/dev/null
        ip link del dev $MIF 2>/dev/null
        ;;
*)
esac
 
I loosely based my design on Lede/OpenWRT scripts such layer_cake, not on CakeQOS. I'm going with diffserv3 on the upstream because most VoIP solutions will use DSCP out of the box (both my work VoIP phone and my home ATA do). This will allow improved VoIP handling, which is more important IMHO than just trying to get the nicest latency charts off test sites.

This is an example of a QoS script generated by the firmware on my test setup at this time in development (things are still in flux and are not final):

Code:
#!/bin/sh
ULIF='eth0'
DLIF='eth0'
MIF='ifb4eth0'
ULBW='bandwidth 51200kbit'
DLBW='bandwidth 409600kbit'
OVERHEAD='overhead 38 mpu 84'
FRAMING=''

case "$1" in
start)
# Upload
        tc qdisc add dev $ULIF root cake nat diffserv3 $ULBW $OVERHEAD $FRAMING 2>/dev/null

# Download
        ip link add name $MIF type ifb 2>/dev/null
        tc qdisc add dev $DLIF handle ffff: ingress 2>/dev/null
        tc qdisc add dev $MIF root cake nat wash $DLBW besteffort $OVERHEAD $FRAMING 2>/dev/null
        ip link set $MIF up 2>/dev/null
        tc filter add dev $DLIF parent ffff: prio 10 matchall action mirred egress redirect dev $MIF 2>/dev/null

        ;;
stop)
        tc qdisc del dev $ULIF root 2>/dev/null
        tc qdisc del dev $DLIF ingress 2>/dev/null
        tc qdisc del dev $MIF root 2>/dev/null
        ip link set $MIF down 2>/dev/null
        ip link del dev $MIF 2>/dev/null
        ;;
*)
esac
Appreciate the info. I have 100% agree. I could never quite get a steady/realiable connection with comcast and cake script hence why I was using FlexQoS. It would be good some days but not consistently.

Hope to see a difference and we really do appreciat all your hardwork!

A lot of great stuff coming soon!!!!

Thanks again!
 
No idea, I never played with that. I just saw a reference to using the DSCP target in a Cake-related thread through a quick Google search.
.
Apologies, I am only able to relay half-understood details :).
Maybe touch base with @Odkrys as they seem to know what is required for ingress tagging on OpenWRT.

They are apparently using tc's ctinfo action with OpenWRT, which this firmware doesn't support, but suggests that skbedit presents an alternative approach. skbedit requires "CONFIG_NET_ACT_SKBEDIT" to be set.

Again, this all may be technical-gibberish since I am not fully on top of the implications of any of those functions. ;)

You efforts to get cake baked in a greatly appreciated though. At worst, it sounds like we will have something at least as good as what we have with cake-qos, which is fine by me :).
 
Appreciate the info. I have 100% agree. I could never quite get a steady/realiable connection with comcast and cake script hence why I was using FlexQoS. It would be good some days but not consistently.

Hope to see a difference and we really do appreciat all your hardwork!

A lot of great stuff coming soon!!!!

Thanks again!

You can try cakeqos in the meantime if you would like, with the settings we are currently testing based on @RMerlin post prior. I am curious if the experience is more stable. This is assuming you were using settings that were different to the defaults above. I tended to recommend besteffort for both up/down (which I've had stable from inception), however I have been running with diffserv3/besteffort for the last day and appears just as stable. I know you have been one of the earlier ones on the cake wagon!
 
Only Adaptive QoS requires the Trend Micro engine. None of the other QoS modes do.

Which means both cakeqos (and perhaps suricata_manager) scripts logic need to be tweaked for this. I was pleasantly surprised when I noticed this last night. Win-win for the privacy conscious!!!!!
 
I just saw a reference to using the DSCP target in a Cake-related thread through a quick Google search.
When I went to openwrt I looked for some information about dscp marking for incoming traffic and found it to be pretty hard work.

YkwUi.png (1450×475) (imgur.com)

This is because, as shown in the picture above, iptables is executed after qdisc, so it is impossible to specify dscp for incoming traffic using existing iptables.


There was a way to use veth in the openwrt forum, but I found out that there is a slightly better way with the openwrt firmware.


Openwrt has already implemented a function to save dscp marking information in conntrack table by adding set-dscpmark function to iptables and restore dscp information from qdisc using tc act_ctinfo.

However, asuswrt is an old kernel to add this feature, so I couldn't find a way other than using skbedit.

 
Last edited:
Status
Not open for further replies.

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top