Oops, I guess I assumed that you would had manually configured cake in the first place. Doing it via the GUI is not hard either:
- select the "Link Layer Adaptation" tab (in luci-app-sqm)
- select ""Ethernet with overhead: select for e.g. VDSL2."" in the "Which link layer to account for:" dropdown box
- enter 18 in the "Per Packet Overhead (byte):" field (currently this will be applied symmetrically in ingress and egress direction)
- check the "Show Advanced Linklayer Options, (only needed if MTU > 1500). Advanced options will only be used as long as this box is checked." checkbox
- select either "default", "tc_stab", or "cake" in the "Which linklayer adaptation mechanism to use; for testing only" drop down box.
6.1) if you selected either tc_stab, htc_private here or default and did not select cake as qdisc (and neither piece_of_cake nor layer_cake as "Queue setup script"):
a) enter 64 in the "Minimal packet size, MPU (byte); needs to be > 0 for ethernet size tables:" field.
6.2) if you selected either cake here or default and selected cake as qdisc,
a) select the "Queue Discipline" tab
b) check both the "Show and Use Advanced Configuration. Advanced options will only be used as long as this box is checked." and the "Show and Use Dangerous Configuration. Dangerous options will only be used as long as this box is checked." checkboxes
c) add "mpu 64" to both the "Advanced option string to pass to the ingress queueing disciplines; no error checking, use very carefully." and "Advanced option string to pass to the egress queueing disciplines; no error checking, use very carefully." fields.
While you are that stage you might want to put the following into "Advanced option string to pass to the ingress queueing disciplines; no error checking, use very carefully.":
"mpu 64 nat dual-dsthost"
and the following into "Advanced option string to pass to the egress queueing disciplines; no error checking, use very carefully.":
"mpu 64 nat dual-srchost"
The "mpu 64" option will make sure the shaper knows all L2 ethernet frames passed to the cable modem are at least 64 bytes (which they are according to ethernet standards)
The "nat" option will instruct cake to look into the kernels network address translation tables to get access to the real internal addresses of packets, this in turn will give the next option ist "bite".
The "dual-XXXhost" option instructs cake to first distribute available bandwidth fairly by IP addresses (and for each IP address it will also give you per-flow-fairness); for ingress the destination address contains your internal addresses, hen dual-dsthost on ingress; for egress it is the source address, hence dual-dsthost. The effect of these two stanzas is per-internal-host fairness, in an ideal world this should make it less annoying if individual hosts in your network are using many flows (like bittorrent). That is the latency increase by bit torrenting should be isolated to those machines that actually are sending/receiving torrent traffic, but other machines on your network should be fine. (Please note that if you try VoIP and heavy torrenting from the same internal computer you still will get bad latency...)
In case you want to connect to your router via a shell/ the command line interface https://wiki.openwrt.org/doc/howto/firstlogin has some instructions. I believe currently LEDE does not allow telnet at all, but will accept ssh without password on first access. In any way I would recommend to avoid telnet even if if it would still work and always use ssh instead. If this does not get you started and enables you to execute anything you want on your router's CLI, please holler (or better start a new topic asking that question explicitly, it would be much more searchable if responses to such questions are not "littered" over otherwise unrelated topics...)
Hope that helps...
ADDED 2022: mpu 64 is not magically correct for all link types this really needs to describe the smallest data frame that is to be accounted against the gross shaper rate. Different technologies have different minimal sizes albeit many are caused by ethernet's 64 byte frame size, but to be a true mpu we still need to add some specific overhead:
cable/DOCSIS:
`mpu 64' (the DOCSIS shaper accounts for the same ethernet fields that count against the minimal 64 byte L2 ethernet frame size)
ethernet:
mpu 84 (this contains the IFG, the preamble and start frame delimiter (SFD), and the inter frame gap (IFG) on top of the fields relevant for docsis)
VDSL2/PTM:
mpu 68 (PTM uses ethernet frames without preamble, SFD, and IFG, but adds an additional 4 bytes for PTM )
ADSL:
all bets are off, ATM/AAL5 encapsulation either include the frame check sequence and hence inherit the ethernet mpu or they do not. No easy way to discern these two options. But to better be safe than sorry:
mpu 96 (this equals the payload of two ATM cells and should be a conservative guess).
