There seems to be or has been a growing demand for imq. We know that it has been removed because "it is a pain to maintain with bleeding edge kernels." post #8 Can this be a comprimse of just patching it for stable release and let those who are want bleeding edge to patch themselves (usually the more advanced users have no issues with doing this anyway).
That's a post from 2011/2012, If there is truly a demand for IMQ and it hasn't been upstreamed (into Linux itself) in eight years (checking the status now), there is probably a good reason.
That www.linuximq.net does not resolve is not a good sign.
IIRC, upstream kernel decided that IFB is a sufficient solution and rejected to merge/contemplate merging IMQ. The biggest difference between the two, as far as I can tell is IMQ would allow to use iptables before qdiscs, making dscp marking much less of a hassle than with tc. I believe that @dlakelan pioneered using a pair of veth interfaces to allow the use of iptables in combination with an ingress shaper.
Also I seem to recall reading about adding an iptables hook to the ingress side, but I have not followed up on that....
IMHO the easiest solution is to simply use a non-wifi primary router and instantiate the internet ingress shaper as egress shaper on the LAN interface, that should allow iptables before shaper with existing kernels and will also avoid the performance penalty inherent in veth/ifb/IMQ. But this only works if wifi is not required or served by a secondary AP....
Since Linux kernel 4.2, Netfilter also comes with an ingress hook that you can use from nftables.
(I can't comment on its availability from iptables)
A somewhat surprising fact is that a tc (traffic control) ingress hook happens before even PREROUTING.
and the ultimate solution is to switch to nftables, where you can apply a table to the ingress queue of the ethernet device and do your marking before the IFB sees the packet (I think... I'm still using veths with nftables)
...personally, I want to try @ldir's solution to copy egress DSCPs to ingress packets of the same flows, which should work quite well for most simple uses. (Except my personal use-cases are so boring, that simple per-IP-fairness with a flow queueing AQM basically solves all my problems, so my motivation to try more involved approaches has a hard time over coming my "always out of time" issues ;))
It does seem useful. I think you could hack this using nftables and a sequence of rules... on egress, if dscp=CS1 then connmark with CS1... then on ingress, if connmark = CS1 then DSCP mark with CS1 etc..
on at least being able to strip out iptables completely from OpenWrt images (as I recall, LuCI drags it back in).
nftables is awesome. It's awesome enough that I honestly think OpenWrt shouldn't try to do firewalls with UCI anymore, it should just come with an nftables template and people should write nftables rules directly... what a great system.
Well, the one thing it is missing is a complete iptables compatibility shim layer. It does have some migration helpers but it would really be helpful if it had an iptables personality (also this would allow the upstream kernel to jettison the iptables backend). But that ship has sailed, I assume (also there is always the risk that nobody ever changes to the new personality, but from sqm-scripts perspective it would be nice to allow a soft migration to nftables, but hey, I have quite a number of brilliant ideas how other projects could sped their time to make my life easier )
well actually, the iptables programs in Debian are now just wrappers for nftables. With OpenWrt the big problem is that the code hooks into iptables underlying stuff directly rather than calling the iptables command line tools.
From the package description in Debian for iptables:
Description: administration tools for packet filtering and NAT The iptables/xtables framework has been replaced by nftables. You should consider migrating now. . iptables is the userspace command line program used to configure the Linux packet filtering and NAT ruleset. It is targeted towards systems and networks administrators. . This package contains several different utilities, the most important ones: . iptables, iptables-save, iptables-restore (nft-based version) . iptables, iptables-save, iptables-restore (legacy version) . ip6tables, ip6tables-save, ip6tables-restore (nft-based version) . ip6tables, ip6tables-save, ip6tables-restore (legacy version) . arptables, arptables-save, arptables-restore (nft-based version) . ebtables, ebtables-save, ebtables-restore (nft-based version)
So by default when you call iptables on modern Debian it actually just translates the request to an NFT command.
Doesn't matter too much, as the git repo is still active and that is all you need.
Patch iptables and the kernel, then makemenuconfig and go.
Gargoyle uses a customised imq (different hook locations) for its qos implementation which allows for much more granularity over rules (given it can now see the pre and post NAT IPs).
I have been keeping a keen eye on the mark cloning idea, and I experimented with veth and came back to imq each time.
The nftables capability is intriguing.
nftables becomes even more interesting (to me at least) as it is (a) readable and understandable, and (b) between being able to define variables (including use of sets of things), being able to include other config files, and having a readable jump directive, becomes even more readable and can be modular.
As an example, I define all my interfaces and IP addresses in a single file and then refer to them by name everywhere else. Comcrap changes my IP address? Make a single-point change in that file, reload, and good to go. A similar approach for a LuCI/UCI interface seems a lot easier than trying to create all the rules based on the inputs.
Well at least the switch to nftables is in the project pipeline: