[Dnsmasq-discuss] Support of labels in --interface

Brüns, Stefan Stefan.Bruens at rwth-aachen.de
Tue Feb 21 19:54:40 GMT 2017

On Di, 2017-02-21 at 18:50 +0000, Simon Kelley wrote:
> The different behavior is certainly undesirable, and can be fixed.
> Unfortunately, I can only see how to easily fix it so that the
> --bind-interfaces case works the same way as the default.
> The problem is that the sockets API tells you the interface that the
> packet arrived on, and that's what's checked with -i. In your
> example,
> queries send to and both arrive at
> interface virbr0, so there's no easy way to tell them apart, except
> by
> looking at the address they were sent to and correlating that with
> the
> list of interfaces and their addresses .
> That requires an up-to-date list of all interfaces, which means, if
> you're going to behave well in the face of interfaces and addresses
> coming and going, enumerating the list for every packet received,
> which will likely kill performance.
> My feeling is that consistency is good, so I'll certainly make a
> change, the question is, is the current behaviour of -i <interface
> name> as encompassing _all_ addresses associated with the interface
> OK?

You can get the destination address for datagrams from the IP_PTKINFO
auxiliary data:

man 7 ip
IP_PKTINFO (since Linux 2.2)
              Pass an IP_PKTINFO ancillary message that contains a
pktinfo structure that supplies some information about the incoming
              This only works for datagram oriented sockets.  The 
argument is a flag that tells the socket whether the IP_PKTINFO message
should be passed or not. The message itself can only be sent/retrieved
as control message with a packet using recvmsg(2) or sendmsg(2).

    struct in_pktinfo {
        unsigned int   ipi_ifindex;  /* Interface index */
        struct in_addr ipi_spec_dst; /* Local address */
        struct in_addr ipi_addr;     /* Header Destination address */

Kind regards,


More information about the Dnsmasq-discuss mailing list