"richardvo...@gmail.com" <richardvo...@gmail.com> wrote: >On Wed, May 11, 2011 at 4:03 AM, Ed W <li...@wildgooses.com> wrote: >> On 11/05/2011 01:32, richardvo...@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@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.
