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: >>> <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 >> >> >>> $ 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 <interface >> name> as encompassing _all_ addresses associated with the interface OK? >> >> >> >> Cheers, >> >> Simon. >> >> >> >> >> >>>  >>> 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 Dnsmasqfirstname.lastname@example.org >>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> >> >> _______________________________________________ >> Dnsmasq-discuss mailing list >> Dnsmasqemail@example.com >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> >> >> >> _______________________________________________ >> Dnsmasq-discuss mailing list >> Dnsmasqfirstname.lastname@example.org >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Description: OpenPGP digital signature
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasqemail@example.com http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss