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

[Brüns, Stefan]

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 192.168.122.1 and 192.168.122.254 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
packet.
              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,

Stefan