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

[richardvoigt at gmail.com]

On Wed, May 11, 2011 at 4:03 AM, Ed W <lists at wildgooses.com> wrote:
> On 11/05/2011 01:32, richardvoigt at gmail.com wrote:
>>> Note that it's the nf_mark we will be setting. But:
>>>        get/setsockopt(fd, SOL_SOCKET, SO_MARK, ...)
>> That allows you to set a mark for your outgoing packets, and find out
>> what mark is in effect on outgoing packets.
>>
>> There's still a large piece of the puzzle missing, namely finding out
>> what mark is carried by incoming requests, since this determines that
>> mark that goes on the forwarded query (when it cannot be answered from
>> cache).
>
>
> This is where "conntrack" comes in.  Please have a look back at my
> previous email where I try and show the interaction between iptables and
> conntrack?

[snip]

You've explained all that several times, and it's nothing not already
familiar to iptables users.  But those marks are usually read by an
iptables kernel module.  How does dnsmasq, which uses the Berkeley
sockets API (and some OS-specific extensions and ioctls) get the mark
information for datagrams it receives?  Or are you proposing that
dnsmasq use iptables to receive request datagrams instead of the
mostly portable socket functions?

You did mention that squid is capable of this, although on TCP stream
sockets instead of UDP datagram sockets.  There's quite a bit of
discussion here:
http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/34286

I'm just afraid that the CAP_NET_ADMIN (or root) requirement and
changing the way packets are received might be more than Simon is
willing to pursue.