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

2017-03-17 Thread Simon Kelley 
That seems a good solution. Patch applied, with the man=page changes
re-written and expanded.


Cheers,

Simon.


On 14/03/17 15:11, Petr Menšík wrote:
> Hi,
> 
> I have prepared two patches with suggestion how to fix it.
> 
> Patch 1 warns when a label is used for --interface in default mode.
> Patch 2 corrects manual page about real behavior of --interface with
> labels. Feel free to change it, I am not very good at complicated
> sentences in English.
> 
> I think changing it back again to use all addresses including labels
> would be wrong. Let's just warn user about unexpected results.
> 
> Hope that helps,
> Petr
> 
> Dne 21.2.2017 v 19:50 Simon Kelley napsal(a):
>>> The first problem is, manual page is not updated. It tells you
>>> cannot use labels, but you can. Also it does not tell you you can
>>> use -i eth0,eth0:0,eth0:1,lo, but that is minor change.
>>
>> Documentation point taken.
>>
>>
>>> Labels are now supported and dnsmasq is able to bind only to
>>> secondary IPv4 interface with different address. (Since 2.67!) It
>>> works well with --bind-interfaces. However it has inconsistent
>>> behavior with and without that option.
>>
>>> Let's say my configuration is: 4: virbr0:
>>>  mtu 1500 qdisc noqueue state UP
>>> group default qlen 1000 link/ether 52:54:00:2b:ee:d3 brd
>>> ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope
>>> global virbr0 valid_lft forever preferred_lft forever inet
>>> 192.168.122.254/24 scope global secondary virbr0:1 valid_lft
>>> forever preferred_lft forever
>>
>>
>>> $ dnsmasq -i virbr0 will respond to queries to both addresses. It
>>> might be useful backward compatibility feature. However $ dnsmasq
>>> -i virbr0:1 Will respond only on address 192.168.122.254. Ok, call
>>> it a feature.
>>
>>> Problem is, $ dnsmasq -i virbr0 -z Will respond only on address
>>> 192.168.122.1, as I would expect.
>>
>>> $ dnsmasq -i virbr0:1 -z Behaves the same way, as without -z.
>>
>>> I think different behavior is an error. It might be a feature, but
>>> even then, it has to be documented. Opinions?
>>
>> 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.
> No, please don't do that. I think current state is the best version we
> can prepare now. Just correct the documentation and warn user if he or
> she tries to use unsupported combination.
>>
>> 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 > name> as encompassing _all_ addresses associated with the interface OK?
>>
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>>
>>
>>
>>> [1]
>>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42c4d
>> 7e7dba32b6e64a3687d43928bc8e
>>
>>>  Cheers, Petr -- Petr Menšík Software Engineer Red Hat,
>>> http://www.redhat.com/ email: pemen...@redhat.com  PGP: 65C6C973
>>
>>
>>> ___ Dnsmasq-discuss
>>> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
>>
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2017-03-14 Thread Petr Menšík 
Hi,

I have prepared two patches with suggestion how to fix it.

Patch 1 warns when a label is used for --interface in default mode.
Patch 2 corrects manual page about real behavior of --interface with
labels. Feel free to change it, I am not very good at complicated
sentences in English.

I think changing it back again to use all addresses including labels
would be wrong. Let's just warn user about unexpected results.

Hope that helps,
Petr

Dne 21.2.2017 v 19:50 Simon Kelley napsal(a):
>> The first problem is, manual page is not updated. It tells you
>> cannot use labels, but you can. Also it does not tell you you can
>> use -i eth0,eth0:0,eth0:1,lo, but that is minor change.
> 
> Documentation point taken.
> 
> 
>> Labels are now supported and dnsmasq is able to bind only to
>> secondary IPv4 interface with different address. (Since 2.67!) It
>> works well with --bind-interfaces. However it has inconsistent
>> behavior with and without that option.
> 
>> Let's say my configuration is: 4: virbr0:
>>  mtu 1500 qdisc noqueue state UP
>> group default qlen 1000 link/ether 52:54:00:2b:ee:d3 brd
>> ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope
>> global virbr0 valid_lft forever preferred_lft forever inet
>> 192.168.122.254/24 scope global secondary virbr0:1 valid_lft
>> forever preferred_lft forever
> 
> 
>> $ dnsmasq -i virbr0 will respond to queries to both addresses. It
>> might be useful backward compatibility feature. However $ dnsmasq
>> -i virbr0:1 Will respond only on address 192.168.122.254. Ok, call
>> it a feature.
> 
>> Problem is, $ dnsmasq -i virbr0 -z Will respond only on address
>> 192.168.122.1, as I would expect.
> 
>> $ dnsmasq -i virbr0:1 -z Behaves the same way, as without -z.
> 
>> I think different behavior is an error. It might be a feature, but
>> even then, it has to be documented. Opinions?
> 
> 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.
No, please don't do that. I think current state is the best version we
can prepare now. Just correct the documentation and warn user if he or
she tries to use unsupported combination.
> 
> 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  name> as encompassing _all_ addresses associated with the interface OK?
> 
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> 
> 
>> [1]
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42c4d
> 7e7dba32b6e64a3687d43928bc8e
> 
>>  Cheers, Petr -- Petr Menšík Software Engineer Red Hat,
>> http://www.redhat.com/ email: pemen...@redhat.com  PGP: 65C6C973
> 
> 
>> ___ Dnsmasq-discuss
>> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
From c3d10a1132ada7baa80914f61abb720f94400465 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?= 
Date: Tue, 14 Mar 2017 15:23:22 +0100
Subject: [PATCH 1/2] Warn when using label in default mode

---
 src/dnsmasq.c |  2 ++
 src/dnsmasq.h |  3 ++-
 src/network.c | 13 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/src/dnsmasq.c b/src/dnsmasq.c
index 456b0e8..d2cc7cc 100644
--- a/src/dnsmasq.c
+++ b/src/dnsmasq.c
@@ -771,6 +771,8 @@ int main (int argc, char **argv)
 
   if (option_bool(OPT_NOWILD))
 warn_bound_listeners();
+  else if (!option_bool(OPT_CLEVERBIND))
+warn_wild_labels();
 
   warn_int_names();
   
diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index a27fbc1..6b44e53 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -522,7 +522,7 @@ struct ipsets {
 struct irec {
   union mysockaddr addr;
   struct in_addr netmask; /* only valid for IPv4 */
-  int tftp_ok, dhcp_ok, mtu, done, warned, dad, dns_auth, index, multicast_done, found;
+  int tftp_ok, dhcp_ok, mtu, done, warned, dad, dns_auth, index, multicast_done, found, label;
   char *name; 
   struct irec *next;
 };
@@ -1252,6 +1252,7

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

2017-02-23 Thread Simon Kelley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


> But you can also be notified about interface changes via a netlink 
> socket, so you can cache the interface information.
> 

See my reply to Petr: there is an option for that but it's not the
default for historical reasons.



Cheers,

Simon.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYr0t5AAoJEBXN2mrhkTWi4+AP/1kMh6YBHm2vgM3EACZPfLjN
X2IEPBk/dc/3UP3xbjt6ULy3TaNaCT7D0cqmapz0eaqwdlQO1p5Ur+9hFHYvibtP
YtaBhoByRZEPJMj1Fxvl6PpTsoc9XKToaslhOoaPsCJjs4Mi+OqVxmDQ+Yut6fmq
zrO0770Je7oKWMTI5AGUwCrwZw5a1UZQAxYYw1CsUQ6Rk3kuxfdfaSpQZrRnki9B
Vg+3yvKVXqtr/upEUQyOS36BD9MZKzXVrWkGMkZASykDu0PYoH6UdA3RM9B04Sa0
Inhd0M2acLwiDEhkKHpdV0v8vkCoKxPHtQ5EX6ayUcTyEKSPibT6MMVYNhiAvrRw
3MhLK+NGBKKaoeb3WMltQ80dvilgL3B+nr44Ip5FdJzJk9ZfVWsc5VnO+00py9bx
znByq+O8s39lNoN0s0gdlarmAjwdV3Z/0VNQ729hDhP4E3Q+vzSaQeQXmqNFzbuw
saV2lvgLsdFtN1HY0y/C2BPzEujt6ExE/LN5cfCy6BwgMcPgbyzdBy7juTbM6cD7
Das/WP7QtWSWSC+8rth7YPtlAOmP+rVGF8Z1igFC1H1nCb3JnMXiH2lej19Rh4h2
tXHslN9vABMEPaAY5IzJkfZgZ8B7HoskurTdwc1g6+LZnEjmvuLmBTcILRnTcEq9
+zi06zCiBda/iM7Kn2nM
=wVpC
-END PGP SIGNATURE-

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2017-02-23 Thread Simon Kelley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 22/02/17 21:52, Petr Menšík wrote:

> I would suggest a new option then. For example
> --bind-interfaces-exact. It would listen just like
> --bind-interfaces, but would allow you to listen only on virbr0,
> when ignoring any addresses with labels. Current behavior in other
> words, but documented as a new feature. It would allow previous
> behavior at the same time also.

Ugh. There are already _three_ different modes for this.

The default (bind wildcard address), bind-interfaces (bind individual
addresses) and bind-dynamic (bind individual addresses, keep up with
changes in interface config)

On linux, there's actually no sane reason not to use --bind-dynamic,
and it's only not the default for historical reasons. The other two
modes still exist for *BSD where bind-dynamic doesn't exist and you
have the Hobson's choice of the other two: which is least-bad
depending on circumstances.

Since labels are a Linux-only thing, AFAIK, this whole problem may
best be solved by mandating that --bind-dynamic should be used on
linux if you want labels to work, and generating warnings if an label
!= interface name is found in the default mode. Or possibly ignoring
labels entirely in the default mode. And documenting same and that
- --bind-dynamic is needed to use labels. (or maybe --bind-dynamic or
- --bind-interfaces)


Apart from the documentation changes, that would involve removing
label_exception, so pre-2.67 behavior would return for the default
mode, ie --interface must give an interface name and label-aware
behavior would exist in --bind-dynamic ie --interface must give a label.


This stuff is all horrible: it's really difficult to even explain what
it's for and why  it needs to be configured.

Cheers,

Simon.




-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYr0sdAAoJEBXN2mrhkTWi8X0P/irtSCpt0AljtsjwKVhgYj0F
TlidegXBIQvnfk8gFZboI07twkB/iIp5La/xj/erpIDwnAR3/ntnq0yrXHhx27Qe
Ts1V1wHN0RnjxlzxJGiYVLJCE1Q8Pv/ckjdYgXdrXtrINzEer5vzb2/wvP5geyVg
0rx5tn6+JuiabZP0gDJASL1qHyozRgIKp0MNRMCzKrY+SMswjqrKVZwElCxbqELO
kP6mwfLsqzRXjESxLlO4h5TU3QqssfycDeEfuJZdCKUJkrIVEcKTnCjzl3+TNvRN
u/HW9gBWZaU/tKc3qEPlW6Tk8U9DKoXM9n7ml3goyhcBmeAENWHKn5TULoMR/Ns3
74HDDS/CKUgNW8u8iF2JD3yAHR7brki+PIuF5MjzP+czw56J/sWYpi/icHqU8tRH
oNxfONMcN9SmBB7JgQCD/TvlAl8mv/bbCs9QW+QQh/A6OigTudV1fx57Nig0YwvC
0usHS6LmX24PtcYRc/3wTrQFI9rsVBmBWVrYTRU1/b3FyVeLlOIXHK4SQ5fHVnvv
xM3BD1YC6etLZjvYdpRyRw6A9UcYvpbqIzXg+HG4EAgJskxf1lJdOIkYAI+qg+d5
3IeZ82wew1ZfjWTMuHVGwUCKaE1119JIr19iXyTfnrKxzP2dQ3rxZqCiCVNG4Equ
6n5FU197tGikv97kEtWo
=Rxi7
-END PGP SIGNATURE-

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2017-02-23 Thread Brüns , Stefan 
On Mi, 2017-02-22 at 20:51 +, Simon Kelley wrote:
> > 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 */ };
> > 
> 
> Indeed. And that gives you, in one hand, the destination address of
> the datagram, and in the other hand, a whitelist of interface labels.
> The only way to compare the two is to enumerate all the interfaces
> using the netlink interface, which gives you all the addresses of
> each
> interface and their associated labels. If the interface set and
> configuration can change arbitrarily, you need to do that for every
> datagram, which gets expensive.

But you can also be notified about interface changes via a netlink
socket, so you can cache the interface information.

Regards,

Stefan
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2017-02-22 Thread Petr Menšík 
Simon Kelley píše v Út 21. 02. 2017 v 18:50 +:
> > Labels are now supported and dnsmasq is able to bind only to
> > secondary IPv4 interface with different address. (Since 2.67!) It
> > works well with --bind-interfaces. However it has inconsistent
> > behavior with and without that option.
> > 
> > Let's say my configuration is: 4: virbr0:
> >  mtu 1500 qdisc noqueue state UP
> > group default qlen 1000 link/ether 52:54:00:2b:ee:d3 brd
> > ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope
> > global virbr0 valid_lft forever preferred_lft forever inet
> > 192.168.122.254/24 scope global secondary virbr0:1 valid_lft
> > forever preferred_lft forever
> > 
> > 
> > $ dnsmasq -i virbr0 will respond to queries to both addresses. It
> > might be useful backward compatibility feature. However $ dnsmasq
> > -i virbr0:1 Will respond only on address 192.168.122.254. Ok, call
> > it a feature.
> > 
> > Problem is, $ dnsmasq -i virbr0 -z Will respond only on address
> > 192.168.122.1, as I would expect.
> > 
> > $ dnsmasq -i virbr0:1 -z Behaves the same way, as without -z.
> > 
> > I think different behavior is an error. It might be a feature, but
> > even then, it has to be documented. Opinions?
> 
> 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.
I would suggest a new option then. For example --bind-interfaces-exact. 
It would listen just like --bind-interfaces, but would allow you to
listen only on virbr0, when ignoring any addresses with labels. Current
behavior in other words, but documented as a new feature. It would
allow previous behavior at the same time also.
> 
> 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.
I think this already happens if you listen on virbr0:1.

Another option might be getting interface address of by index. If they
would not match with destination of packet, return failure from
iface_check (and let it be accepted by label_exception). You would not
have to enumerate all addresses of all interfaces, only one for current
interface. It adds one more syscall, but it should be faster than
getifaddrs(). ioctl SIOCGIFADDR is already used in dhcp.c.
> 
> My feeling is that consistency is good, so I'll certainly make a
> change, the question is, is the current behaviour of -i  name> as encompassing _all_ addresses associated with the interface
> OK?
I think it is unexpected and should be mentioned in manual page. But it
acted like that before, so it would be not break backward compatibility
at least. If it is fixed in default wild mode, we should note that -i
virbr0,virbr0:* is now required for previous behavior in manual.
> 
> 
> 
> Cheers,
> 
> Simon.
> 
Cheers,
Petr
> 
> 
> 
> > 
> > [1]
> > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42
> > c4d
> 
> 7e7dba32b6e64a3687d43928bc8e
> > 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973


signature.asc
Description: This is a digitally signed message part
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2017-02-22 Thread Simon Kelley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

> 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 */ };
> 

Indeed. And that gives you, in one hand, the destination address of
the datagram, and in the other hand, a whitelist of interface labels.
The only way to compare the two is to enumerate all the interfaces
using the netlink interface, which gives you all the addresses of each
interface and their associated labels. If the interface set and
configuration can change arbitrarily, you need to do that for every
datagram, which gets expensive.


Cheers,

Simon.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYrfngAAoJEBXN2mrhkTWi4GsP/ApliVfiOsVguaMMAfY7MmJX
Q6ieWcPgNrQHXLgKjiJZpof2m9ZOvHKnR37rXNXW6v2x5J3vnRAaigil0j0wEb/u
3R733QI2eNkCOnzAmpO+zKDpkq/KjReEary6znOKp33U1B8kCMpPcJDDx3QZEkjS
qwAMgpsz3IKA+ezNgYbI/311B3RpMGt2XdvUNkHG9JDL2FAroS9/G0/vrmFKaDMZ
1+R09AtJBHvu/fOEbNcnl4r7mwwdMqd6ONPc6oqrah+gOkjdLWQe3M50fZ1aJC0y
r5HH+hp/MobyAxkF7gzbzt4VLG+fGU17ZanJZHRQgKnqsvj1e4pLdCP5wJ/4D1ya
ZlYQ6i3IjCVMXLS+y/tpJtPksnw49soHVOGObIpaT6lEEqX7BgTVvbFPv876aUn/
xkNvE83XzKPJ4LkKTR3cbXi5oJiglmDaClLgq+CRDdgu8cK41o/q6Fbv/gTs7X6N
AHurx+5X7AzArdJdF/cDrt7a7qA5GT7wonUgNZt8xXzW/WWlkMQ878aK2ij2kBFy
AYzeCpqyMyKZ0hEt3VgGo2p5k/cr/Wik5IaaXbrJZC33dRrVAWB6OdAXqmVED9ei
GavpRz+YYwHJaBQoo8ZFjDCEZHqWkFZszMO+B2DuDWYenB/QOCBUYWTEVgfPnPVw
w03CB2ZmjqWfZEHzfiW0
=QPnP
-END PGP SIGNATURE-

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2017-02-21 Thread Simon Kelley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/02/17 17:38, Petr Mensik wrote:
> Hi!
> 
> I am new maintainer of dnsmasq package in RHEL. I am looking for
> potential problems with upgrade from dnsmasq 2.66 to version 2.76.
> And I have found something. Commit [1] changed behaviour of
> --interface eth0:0 behavior.
> 
> The first problem is, manual page is not updated. It tells you
> cannot use labels, but you can. Also it does not tell you you can
> use -i eth0,eth0:0,eth0:1,lo, but that is minor change.

Documentation point taken.

> 
> Labels are now supported and dnsmasq is able to bind only to
> secondary IPv4 interface with different address. (Since 2.67!) It
> works well with --bind-interfaces. However it has inconsistent
> behavior with and without that option.
> 
> Let's say my configuration is: 4: virbr0:
>  mtu 1500 qdisc noqueue state UP
> group default qlen 1000 link/ether 52:54:00:2b:ee:d3 brd
> ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope
> global virbr0 valid_lft forever preferred_lft forever inet
> 192.168.122.254/24 scope global secondary virbr0:1 valid_lft
> forever preferred_lft forever
> 
> 
> $ dnsmasq -i virbr0 will respond to queries to both addresses. It
> might be useful backward compatibility feature. However $ dnsmasq
> -i virbr0:1 Will respond only on address 192.168.122.254. Ok, call
> it a feature.
> 
> Problem is, $ dnsmasq -i virbr0 -z Will respond only on address
> 192.168.122.1, as I would expect.
> 
> $ dnsmasq -i virbr0:1 -z Behaves the same way, as without -z.
> 
> I think different behavior is an error. It might be a feature, but
> even then, it has to be documented. Opinions?

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  as encompassing _all_ addresses associated with the interface OK?



Cheers,

Simon.




> 
> [1]
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=3f2873d42c4d
7e7dba32b6e64a3687d43928bc8e
>
>  Cheers, Petr -- Petr Menšík Software Engineer Red Hat,
> http://www.redhat.com/ email: pemen...@redhat.com  PGP: 65C6C973
> 
> 
> ___ Dnsmasq-discuss
> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYrIvyAAoJEBXN2mrhkTWiWzgP/RKGiOwyCG+IU2MZ5Ax453rM
ALXKz6tyFX/TszMPBLScH65en3IgzL+PrjXDbZu2fXpZXgg957D20wBPfCDHfPxJ
fnBRdWUQpB0W/M8+INJMSrYX+JS5iHfxmm8/5X/zUhedMfB1zhmskOAiHBbcjxCy
vGSvczc9FTNv5Q0/WD9v08EJiEJOfNyOLAGIQILSzVa7HkYpD5nLsJ0rCavoKtFk
OFyK1pA5Kx9QwSlkn7vMco/OU5iTOF9bQ+a7sYJp3mRhXtNdW41HMTEE8J57+tlP
OMkDaKCWnlXDzVfVD0q1cK36aof5IUXukGuuhOx6mEFKSLtpmoZWP7qAhX73KZYk
SKgnnWwZrNgDo5TFYdhCeSIco7bFnQtSgSHgX9VNv/QcLZzZxUfrxbpgyzLO4fvK
TO1YOq8RyHDfHxjS7L8QrPceRck/558L0mNgB09G8y75vIHMNPGghHzCL4AkL1VO
krFCiDrr4GEsGEWx/J2HWagFsRzavFzWAHdkgr2tQ3i7ATThV7+p3tcU164hYoOu
b7fbQk3O+GIpkvuzdG4UWZ4SmrbQ4kl6Q6MMgMsZfXGXqX7SrYXoobn0vPulZxm2
y6SfCTgbjUqTjfkNBNZM3wZyoM77pNhzIZiibHTr388fgbt/5L1xSavlwJqmR5VV
VXeTleBo8BUem7W6BV1B
=pWPX
-END PGP SIGNATURE-

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2017-02-20 Thread Petr Mensik 
I think it is automatic if there is already IP from the same subnet on that 
interface.

$ ip a add 192.168.122.1/24 dev virbr0
# no secondary flag yet, first address of 192.168.122.0/24
$ ip a add 192.168.122.254/24 dev virbr0 label virbr0:1
# secondary flag present, it is second address of 192.168.122.0/24 on that 
device
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

- Original Message -
From: "Simon Kelley" <si...@thekelleys.org.uk>
To: dnsmasq-disc...@thekelleys.org.uk
Sent: Friday, February 17, 2017 1:16:59 PM
Subject: Re: [Dnsmasq-discuss] Support of labels in --interface

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/02/17 17:38, Petr Mensik wrote:
> Hi!

> Let's say my configuration is: 4: virbr0:
> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
> group default qlen 1000 link/ether 52:54:00:2b:ee:d3 brd
> ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope
> global virbr0 valid_lft forever preferred_lft forever inet
> 192.168.122.254/24 scope global secondary virbr0:1 valid_lft
> forever preferred_lft forever
> 

Quick question from the lazy: how do you set the "secondary" flag on
the second address?

ip addr add  dev virbr0 label virbr0:1

doesn't seem to.

Dunno if it matters, just want to replicate this exactly


Cheers,

Simon.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYpum7AAoJEBXN2mrhkTWi74gP/A1nDuRres/jwNlJBBa1Ooa1
GFS3gGsMTxlZpank4bsH9MUnezzLMwkTa/F3Pz2jztnVzGwSplmZqtqFQErYaLWR
wyJXGGeNNlRt/u2dChLMWTO/qyf2AVfa+Ght66npzwJ0laVVkBishPHDcCKPhLIY
Rv5+WSsgqFgUwMFpjj8xj0WJJU7iNjCG4G9dwlmHu9kElwnW9xiL9dC6dDZuLOrd
GHlDodp7c5L5R7UQkvnfmlLWCOgz6/21Z1LkLBlsDyjpQcX+e7G5shb7r2UEEX0o
5RX2+3utnyGAGysiaVF9logiGCN7Hx/dBhvwtrvdcDSxa944GavLtHVSftuwIGZG
RDZIMea2DixSJUuOjGJ0MIfLg6IeoigSGIlNgLP++EupOz6fqxT2iJbaQ0M4Mqtm
H6haQkMT7Xj5OUfdfptXmR89idQRoPP7WIGU8CPQrs70vLpdGwKoF7nbT3KqeVpK
C+9CvHAxFKtWoElIzVPn7Oa2Zz/alXBBXdIfRg5TEP0QrJZCgPBixZ9Yy5F2fVxE
fP88SazdH7Yq6HDlS6KfPPq6N+0IklD0Y6GoBcchxxPpJpKFCkhXAS8EKFb04QLg
ZgPOzu73LFmed9YAXSFggR+eMmxN2M5ImPidiW8/xLCvHgtvn3/EOEi3VcU2gOS6
wczS9ivnbdarmpyPP4i/
=8wXW
-END PGP SIGNATURE-

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2017-02-17 Thread Simon Kelley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/02/17 17:38, Petr Mensik wrote:
> Hi!

> Let's say my configuration is: 4: virbr0:
>  mtu 1500 qdisc noqueue state UP
> group default qlen 1000 link/ether 52:54:00:2b:ee:d3 brd
> ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope
> global virbr0 valid_lft forever preferred_lft forever inet
> 192.168.122.254/24 scope global secondary virbr0:1 valid_lft
> forever preferred_lft forever
> 

Quick question from the lazy: how do you set the "secondary" flag on
the second address?

ip addr add  dev virbr0 label virbr0:1

doesn't seem to.

Dunno if it matters, just want to replicate this exactly


Cheers,

Simon.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJYpum7AAoJEBXN2mrhkTWi74gP/A1nDuRres/jwNlJBBa1Ooa1
GFS3gGsMTxlZpank4bsH9MUnezzLMwkTa/F3Pz2jztnVzGwSplmZqtqFQErYaLWR
wyJXGGeNNlRt/u2dChLMWTO/qyf2AVfa+Ght66npzwJ0laVVkBishPHDcCKPhLIY
Rv5+WSsgqFgUwMFpjj8xj0WJJU7iNjCG4G9dwlmHu9kElwnW9xiL9dC6dDZuLOrd
GHlDodp7c5L5R7UQkvnfmlLWCOgz6/21Z1LkLBlsDyjpQcX+e7G5shb7r2UEEX0o
5RX2+3utnyGAGysiaVF9logiGCN7Hx/dBhvwtrvdcDSxa944GavLtHVSftuwIGZG
RDZIMea2DixSJUuOjGJ0MIfLg6IeoigSGIlNgLP++EupOz6fqxT2iJbaQ0M4Mqtm
H6haQkMT7Xj5OUfdfptXmR89idQRoPP7WIGU8CPQrs70vLpdGwKoF7nbT3KqeVpK
C+9CvHAxFKtWoElIzVPn7Oa2Zz/alXBBXdIfRg5TEP0QrJZCgPBixZ9Yy5F2fVxE
fP88SazdH7Yq6HDlS6KfPPq6N+0IklD0Y6GoBcchxxPpJpKFCkhXAS8EKFb04QLg
ZgPOzu73LFmed9YAXSFggR+eMmxN2M5ImPidiW8/xLCvHgtvn3/EOEi3VcU2gOS6
wczS9ivnbdarmpyPP4i/
=8wXW
-END PGP SIGNATURE-

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss