[Dnsmasq-discuss] Very accurate bandwidth tracking...

Ed W lists at wildgooses.com
Tue May 10 16:48:06 BST 2011


On 10/05/2011 09:53, Simon Kelley wrote:

> There's two stages to think about. One: a requestor sends a UDP request
> to dnsmasq. All of these are received by dnsmasq through the same
> listening socket, or a best through a very few sockets.

I'm not 100% sure, but given that dnsmasq can ensure that every reply
packet is correctly tagged with the correct mark, I don't think it will
matter whether conntrack works correctly for client -> dnsmasq

> We need some way
> of getting the conntrack information associated with individual packets,
> not sockets. Is that possible?

Just to be clear - I believe that applications apply firewall "marks",
which are confusingly different to conntrack marks

The process is something like:

- iptables (or dnsmasq) applies a firewall "mark" to a packet
- this is copied up to the connection tracking "mark"
- on return packets from outside we can request that conntrack --restore
the firewall mark based on the "connection tracking" state

I am learning this as well so I hope I got that perfectly correct...

So, I believe we only test for and apply firewall marks...
	setsockopt(fd, SOL_SOCKET, SO_MARK, ...)

(Quick check, but probably call them nf_mark and conntrack_mark for clarity)



> Two: the request gets sent upstream.
> There is _normally_ a new socket for each request (for source-port
> randomisation), so that's fine. The exceptions to this probably don't
> matter (source-port randomisation configured off, very heavy load where
> sockets are re-used to avoid resource use growing without bound.)

This works for me.

What I'm not 100% sure of is whether anything special is required to
change the conntrack_mark during a connection? ie can you apply an
nf_mark at the start of a connection, that gets copied up to be a
conntrack mark, then what happens if you switch the nf_mark during the
connection?

This will only occur it seems under heavy stress, but the two options
are either: a) it works fine if the connection flip flops it's nf_mark
b) we should set the nf_mark to zero, which should be picked up as
unmarked traffic by simple iptables rules.  I really have no idea until
I get to try it...  Suggest a) seems best at this stage, to put a stake
in the ground...


> Given the abilty to read the conntrack mark for an incoming request, and
> set the conntrack mark for a socket-to-upstream, the rest is trivial in
> implement.

Note that it's the nf_mark we will be setting. But:
	get/setsockopt(fd, SOL_SOCKET, SO_MARK, ...)

I hope this makes implementation feasible?


Oh, I found this page with some examples on firewall marks:
	http://home.regit.org/netfilter-en/netfilter-connmark/

Also see any discussion on "policy routing" - generally firewall marks
are used for routing decisions.  You can use iptables to mark packets in
a certain way, then conntrack takes care of perpetuating that mark
through time, finally you can route or account based on that mark.  Cool
huh.

For testing I guess apply a mark based on IP address of the test client
machine, then see if you can do something trivial with filtering the
output of dnsmasq using the output mark? (I guess I need to supply
iptables rules for that, but I'm not fluent enough to crack them out
without testing first...)

Thanks for looking into this

Ed W



More information about the Dnsmasq-discuss mailing list