[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 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
More information about the Dnsmasq-discuss
mailing list