What-ho Chaps!
With nervousness and trepidation I'm submitting the attached RFC patch
for an extension to 'connmark'.
savedscp-mark is designed to copy DSCPs to conntrack marks and is
intended to be used with a tc filter based companion action currently in
the process of being submitted called 'conndscp'. The TC people are ok
with extracting information from conntrack connmarks but are much less
keen on TC changing those marks. Hence the requirement to split the
functionality across two subsystems 'tc' & 'netfilter'.
At this stage I'm primarily interested in whether an extension to
xt_connmark that writes DSCP to conntrack marks for late use/pickup by a
tc filter is acceptable in terms of concept.
The feature is intended for use and has been found useful for restoring
ingress classifications based on egress classifications across links
that bleach or otherwise change DSCP, typically home ISP Internet links.
Restoring DSCP on ingress on the WAN link allows qdiscs such as CAKE to
shape inbound packets according to policies that are easier to implement
on egress.
Ingress classification is traditionally a challenging task since
iptables rules haven't yet run and tc filter/eBPF programs are pre-NAT
lookups, hence are unable to see internal IPv4 addresses as used on the
typical home masquerading gateway, hence the efforts in trying to
restore a classification on ingress based on a classification made on
egress.
x_tables CONNMARK with the new savedscp action solves the problem of
storing the DSCP to the conntrack mark.
It accepts 2 parameters. The mark is a 32bit value with usually one
bit set. This bit is set when savedscp saves the DSCP to the mark.
This is useful to implement a 'one shot'
iptables based classification where the 'complicated' iptables rules are
only run once to classify the connection on initial (egress) packet and
subsequent packets are all marked/restored with the same DSCP. A mark
of zero disables the setting of a status bit/s.
The mask is a 32bit value of at least 6 contiguous bits and represents
the area where the DSCP will be stored.
e.g.
iptables -A QOS_MARK_eth0 -t mangle -j CONNMARK --savedscp-mark \
0x01000000/0xfc000000
A typical example of using savedscp-mark to store DSCP values for use
with a tc conndscp & hence qdisc (e.g. CAKE) is shown below, using top 6
bits to store the DSCP and the bottom bit of top byte as the state flag.
#iptables rules using the statemask flag to only do it once
iptables -t mangle -N QOS_MARK_eth0
iptables -t mangle -A QOS_MARK_eth0 -m set --match-set Bulk4 dst -j DSCP \
--set-dscp-class CS1 -m comment --comment "Bulk CS1 ipset"
#add more rules similar to above as required
#save the DSCP into conntrack mark & set the 'marked' bit
iptables -t mangle -A QOS_MARK_eth0 -t mangle -j CONNMARK --savedscp-mark 0x01000000/0xfc000000
# send unmarked packets to the marking chain
iptables -t mangle -A POSTROUTING -o eth0 -m connmark --mark 0x00000000/0x01000000 -g QOS_MARK_eth0
I am not a full time programmer in any language, xt_connmark &
tc/conndscp represent something of the order of a 3 week struggle, my C
is awful, kernel & network knowledge worse, though I like to think
improving. There are no doubt issues with this patch/feature but I hope
constructive feedback, quite possibly in very short words for my simple
brain, will knock it into shape.
More importantly is the 'connmark --savedscp-mark' concept fatally
flawed in some way that it cannot be made acceptable?
Your time, comments & guidance appreciated.
Kevin Darbyshire-Bryant (1):
netfilter: connmark: introduce savedscp
include/uapi/linux/netfilter/xt_connmark.h | 3 ++-
net/netfilter/xt_connmark.c | 30 ++++++++++++++++++++++
2 files changed, 32 insertions(+), 1 deletion(-)
--
2.17.2 (Apple Git-113)
