Hi everyone,
I'm trying to configure (OK, 'hack') a Linux-based Broadcom wireless gateway to prioritize the traffic between two groups of interfaces, e.g. where home traffic gets rate 80% ceil 95% prio 1, and where guest traffic (i.e. wl1) gets rate 15% ceil 60% prio 2.
I now have tc doing this beautifully on the uplink traffic (I use 'action skbedit mark 1', why is this trick mentioned hardly anywhere?): but, like almost every other first time poster here :-) , I'm having no luck at all getting this working for downlink traffic.
Specifically, I've put in a lot of work trying to get IFB working, but it seems to be stitched too early in the packet processing chain to be any use for shaping a WAN interface's downlink traffic. Basically, my downlink bandwidth stats stay resolutely at zero bytes / zero packets, whatever I try. :-(
Are there any higher-level (i.e. device-level) configuration alternatives to using IFB? It seems obvious to me that if I could insert any (fake, forwarding-only) device at all between the WAN port and the rest of the system, then I would be able to use normal tc egress shaping on the traffic going through it.
It strikes me that this would be something a tap device could do, for example: but I've never seen anyone discuss this anywhere on the web.
Anyway, I'm currently using eth3 for the WAN, so my (working) uplink traffic shaping looks like this:-
eth0-2 / wl0 ---> br0 ---> \
+---> [tc egress] eth3 --> [Internet]
wl1 ---> /
For the downlink, however, I'm wondering if there might be a fake device I could configure in that serves only to forward packets. tap0?
eth0-2 / wl0 <--- br0 <--- \
+ <--- fakedevice [tc egress] <--- eth3 <--- [Internet]
wl1 <--- /
I was hoping (of course) that IFB would be able to do this for me, but it doesn't seem to want to play nicely. Am I missing something? All suggestions and comments very much appreciated! :-)
Thanks very much, Nick--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
