[Dnsmasq-discuss] [PATCH] Two small fixes
pemensik at redhat.com
Wed Sep 29 10:55:58 UTC 2021
I do not remember it well also. But I think it was there to allow
--interface=eth0:0 on startup and do actually something, when started
without --bind-interfaces. I think there was issue with indextoname
converting arrival packet index to a name. If it were not marked as
label and handled special way, incoming packet never matched eth0:0
interface name, because only eth0 got reported as incoming interface.
Therefore it warns different interface name is in effect, which might
include more listening addresses than intended.
I suspect Dominik's would break some use-case, though I am not sure
which. Was the change tested with existing label interface and both with
--bind-interfaces parameter and without? It seems risky, I think those
interfaces system is a bit fragile and small changes often break
something not obvious. I doubt --no-dhcp-interface=eth0:0 may even work,
DHCP is working on lower levels.
Not worth changing unless we know for sure we want/need it.
On 9/28/21 00:03, Simon Kelley wrote:
> On 18/09/2021 19:20, Dominik DL6ER wrote:
>> Patch 1 fixes an ambiguity with interface names when virtual
>> interfaces are present.
>> I'm not exactly sure it has no unintended side-effects, however,
>> it seems to be the right thing to do in my understanding of the
>> code. Otherwise, virtual interfaces cannot really be
>> distinguished from real interfaces later in the code. This may be
>> a problem when there is more than one virtual interface as iface-
>>> label will be non-zero for all of them. For instance,
>> warn_wild_labels() will log the same string multiple times if
>> more than one virtual interface is present.
> Petr, this code seems to have last been touched by you, in
> can you remember what that was supposed to achieve? None of it is making
> much sense to me.
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
More information about the Dnsmasq-discuss