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

Simon Kelley simon at thekelleys.org.uk
Wed May 11 14:59:35 BST 2011


"richardvoigt at gmail.com" <richardvoigt at gmail.com> wrote:

>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.
>
>_______________________________________________
>Dnsmasq-discuss mailing list
>Dnsmasq-discuss at lists.thekelleys.org.uk
>http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

CAP_NETADMIN is already in use for the DHCP side, so that's not a problem. Libnetfilter_conntrac dependency is a bit of a problem, but should be OK.

Simon.



More information about the Dnsmasq-discuss mailing list