Eric wrote:But it looks like for some reason this configuration works with the FORWARD chain, but not the INPUT chain.
The reason for this is that traffic moving through the FORWARD chain eventually gets to the POSTROUTING chain where the IMQ target can take effect. Traffic in the INPUT chain ends up at a router process and never gets to the IMQ device. Tricky.
Eric wrote:I'm not sure if moving IMQ passthrough to PREROUTING and restoring from the connmark is worth the tradeoff (given that it's working in FORWARD), just to handle INPUT packets.
This is as they say the nut of the matter. I have finished coding your basic idea. The only downside I have found is that relying on the connmark for ingress QoS means that some traffic (non-connection oriented) cannot be marked into anything but the default class. I only have three chains as you suggested.
qos_ingress (INPUT, FORWARD)
So now we must pick our poison. For the vast majority of users this issue will never effect them. However, that semi-power user who loads one of the many cool optional packages available for OpenWRT will get surprised, disappointed or confused. On the other hand that ill informed novice who makes his default ingress class something with a ridiculously low quota (like <1%) will find his entire network suffers if there is non-connection oriented traffic flying around.
I'm still pondering this but favoring making the change to allow router traffic to be classified.