So I’m not trying to run DHCP and Nat etc. on the PI as I already have a router running all the following. I thought since I don’t want the pi as a router a bridge is the only option .
what's the use case then, your current two Ethernet port setup makes it a very expensive RJ45 coupler.
In a transparent bridge setup, CAKE SQM sits between my fibre box and main router, without handling routing or DHCP. It acts as an invisible Layer 2 bridge, passing traffic through while shaping it. To enable the upstream upload QoS, ingress traffic from my router enters the Pi via one Eth 0 passes through the software bridge (br-lan), and is intercepted using tc (traffic control) filters. This traffic is redirected to the virtual appliance ifb0, where CAKE SQM is done traffic is shaped and exits the Pi to the modem. I’ve heard doing this setup allows you keep my existing router fully in control of the network.
This is normally known as a switch. Switches don’t generally shape traffic.
A layer 2 device works at the data link layer. In that environment, it’s forwarding packets from source to destination on the same network. And here, we’re talking about ethernet frames. Frames are frames. Or to borrow a line from George Kostanza: “it’s all pipes!”. A true L2 device doesn’t have any information about the type of traffic or its ultimate destination… it just knows the L2 IP addresses (and MAC addresses) of the source/destination on that network.
For example, assume you have a computer connected to an L2 device (a switch or AP) which then connects to your router. Now, on your computer, you navigate to a website or join an online game or a video call… the data flows from your computer to the switch, and the switch sees that the traffic needs to go to the router, so it forwards the traffic accordingly. Your switch does not know the nature of the data inside the frames, though. The router (L3) now has information about the true destination IP address and sends packets out the wan, and it also has insight into the protocols and ports. It is at L3+ that you can actually shape traffic.
From where did you hear that you can have a transparent L2 bridge that can shape traffic?
I spoke to a network expert I was troubleshooting an issue realised it was caused from the WAN side . A transparent Layer 2 (L2) bridge using CAKE SQM works by leveraging a Linux bridge (br0) to connect two physical interfaces eth0 and eth1 so that traffic can pass through without any IP address or routing making the device invisible to the network. However, since bridged traffic normally bypasses the Linux traffic control stack, shaping it requires an intermediate workaround. This is done using IFB (Intermediate Functional Block) device, that acts as a virtual interface to redirect and intercept ingress traffic. By me attaching a tc filter on the bridge interface, ingress packets are mirrored and redirected to the IFB device, where CAKE can then be applied to shape the traffic.Egress traffic can be shaped more directly by applying CAKE on the outgoing physical interface. I’ve heard this works because CAKE, and Linux QoS in general, requires traffic to pass through a network interface with a qdisc attached, and IFB provides a way to insert bridged traffic into that path without breaking the L2 transparency. Then this is a fully transparent bridge capable of advanced traffic shaping without routing, NAT, or changing my current network .
Can anyone help me with this ? Doesn’t seem to work. These last few weeks have been my first time using open wrt not sure of how to configure everything , carry on running into issues such as IPV6 and DHCP6. Issues , failure to update opkg , br lan refusing connection after it had obtained an ip and more .
You don’t believe the advice you have gotten to date that you cannot make an openwrt traffic shaper that is also a transparent l2 bridge on the wan side of your router?
No I know it will still work. I explained earlier, why it works, someone can let me know if the concept is flawed not allowing it to work.
I’ve never done it, and I don’t intend to spend time on creating a lab setup for it, but you could make yourself familiar with the wifi/relay_configuration guide, relayd between two wired vlans, add a vlan aware switch to your Pi and check if QoS works on the relayd interface.
I honestly have no clue if that’s even close to what you sound so sure to be possible, but it’s the closest I can imagine.
Thanks I will try , I’ve heard a simpler way to try it is by setting eth 0 and 1 in the br lan and changing protocol to unmanaged , so it receives dhcp from fibre box and then configuring sqm and disabling firewall and Dnsmasq.
Just to be clear...
This effectively makes eth0 and eth1 part of a (software defined) unmanaged switch. This means that traffic flows through this without any interaction with the CPU (except insofar as the software bridge requires the CPU, but it's basically just copying the data from one interface and sending it out the other, nothing more).
An unmanaged interface, by definition, does not get an address at all. It will not get a DHCP issued address from the fiber box.
What you are creating is a very expensive wire.
That’s not quite right in a Linux-based transparent bridge for SQM, the interfaces themselves usually don’t have IPs, but that doesn’t mean they’re “unmanaged” in the switch sense or that it’s “just a wire.” Without IPs, the interfaces still fully participate in the kernel’s networking stack at Layer 2, and with SQM enabled, every packet is intercepted by the CPU, queued, shaped, and scheduled before being sent out. An unmanaged switch forwards in hardware with no per-packet CPU involvement; a Pi 5 with SQM is actively processing and controlling traffic flow in software
Ok... I'll look forward to learning from your solution.
If everyone is confident it doesn’t work, you should be able to explain why in terms of the Linux packet path and qdisc behaviour in bridge mode. Just saying ‘it doesn’t’ without a technical breakdown. I’ve explained the processing path and CPU involvement. Unless anyone can point to where that’s wrong, it sounds like you’re just repeating what everyone has told me , I know technically it will work , I just haven’t had experience using openwrt before , I’m running into issues preventing me from completing the configuration that’s the issue.
I have been trying to explain this, but let's try another approach.
Do you agree that a bridge is an L2 (data link) device? (it is, but I want to make sure you aren't making an argument otherwise.)
OSI layer 3 is the network layer. This is where the routing/firewall happens) and layer 4 (transport) is where TCP comes into play and controls the actual data flow, including data transmission speeds and also error correction.
When you consider traffic shaping, there is no way that an L2 bridge can do this since it has no concept of the data type that is being passed through the medium -- it's simply moving ethernet frames between devices. This must be done at L3 and/or L4 where some of the underlying data can be evaluated for shaping.
1 Like
You think Linux bridging behaves like a pure hardware L2 switch, but that’s not the case. In Linux, a bridge is a kernel construct that still passes packets through the networking stack. With tc + CAKE/FQ_CoDel, traffic shaping can be applied at the egress qdisc of a physical interface, regardless of whether it’s in a bridge or has an IP. The kernel doesn’t need full L3/L4 awareness to shape shaping is based on byte counts, queue depth, and timing, and CAKE optionally inspects L3/L4 headers for flow isolation. This is why OpenWRT supports SQM on bridged interfaces. The OSI model is a conceptual guide, but in software-defined networking on Linux, layers are not strict physical separations L2 devices in Linux can and do perform shaping. OSI model I’m very familiar with but Linux doesn’t operate that same way when following the model . Remember the OSI model is a reference and your applying this to a software defined system that doesn’t follow it.
I don't mind it if I'm proven wrong -- I'll happily learn from my mistakes and I'll do it in plain view (I typically strikethrough anything that is incorrect and I'll point to the post(s) that provide the right information). I say this in all honesty, and I think it's really valuable to both experience and demonstrate that learning process.
With that in mind, I can't see a path forward for your particular method, but if I am wrong, I'll be excited to learn how it can work.
For now, though, I don't have anything else to offer (and in all seriousness, hopefully someone will prove me wrong -- please tag me to tell me if/when that happens).
1 Like
No problem thanks for the help I’m going to work on it tomorrow il let you know how it goes . Also in the bridge there is a virtual interface that copies the traffic and then applies the traffic control filters using the ifb to the packets so it’s not really a layer 2 bridge if you understand what I mean as Linux doesn’t follow the OSI model rather uses the TCP/IP model it combines layers etc if needed due to the way the networking stack is created on Linux it can hook into packet path and inspect deeper if needed.
@Ray3 - I would suggest that you mark this particular thread as solved for a few reasons:
- The initial issue of getting the Pi5 booted and configured with the additional USB network adapter is now resolved.
- The thread title ("Troubleshooting raspberry pi 5") was a reasonable one for initial bring-up of the device, but is not descriptive insofar as your ultimate goals of traffic shaping. (a new, properly titled thread would make sense for continuing that part of the discussion)
- You've started a new thread that seems to be a broadly related continuation of this one.
As such...
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! 
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.