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. Cheers, Petr 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 > > ad59f278c6234a416f36dfdd39143bb46f5d707a > > can you remember what that was supposed to achieve? None of it is making > much sense to me. > > Simon. > > > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
