[Dnsmasq-discuss] Very accurate bandwidth tracking...
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
>>> what mark is in effect on outgoing packets.
>>> There's still a large piece of the puzzle missing, namely finding
>>> what mark is carried by incoming requests, since this determines
>>> mark that goes on the forwarded query (when it cannot be answered
>> This is where "conntrack" comes in. Please have a look back at my
>> previous email where I try and show the interaction between iptables
>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
>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
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.
More information about the Dnsmasq-discuss