[Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements

[Neil Jerram]

On 09/06/15 22:11, Simon Kelley wrote:
> On 08/06/15 12:37, Neil Jerram wrote:
>> I'm sorry, this is a really old thread that I'm only just now getting
>> back to.
>>
>> As a reminder, it's a set of patches that extend the semantics of
>> --bridge-interface to DHCPv6 and router advertisements.  Our last
>> exchange (as below) was about fixing a subtle difference in behaviour
>> between the v4 and v6 cases, and this email provides the revised patch
>> set that addresses that point, and also:
>>
>> - is rebased to current master
>> - improves the documentation around --bridge-interface, specifically so
>> that it doesn't appear to be for BSD platforms only.
>>
>> My team has been running with this for a while - albeit on a base of
>> 2.72 - so we have some confidence that the patches are correct.
>>
>> Please would you consider merging these patches into upstream dnsmasq?
>
> Yes. How can I resist a patchset which not only updated the
> documentation, but does it in multiple languages?
>
> 0004 made me scratch my head for a while, but I think I got it. The
> method of expanding the alias wildcard is scary, but I can't see a
> better way to do it.
>
>
> A couple of (very small quibbles)
>
> -                    /* The source interface can only appear in at most
> -                       one --bridge-interfaces. */
> +                    /* The source interface! can only appear in at most
> +                       one --bridge-interface. */
>
> Why does the interface get an exclamation mark? That's a typo? (I
> probably only saw this because it's at the end)
>
> second, the DHCPv4 code for the bridging  looks like this.
>
>   for (bridge = daemon->bridges; bridge; bridge = bridge->next)
>      {
>        for (alias = bridge->alias; alias; alias = alias->next)
>          if (wildcard_matchn(alias->iface, ifr.ifr_name, IF_NAMESIZE))
>            {
>              if (!(iface_index = if_nametoindex(bridge->iface)))
>                {
>                  my_syslog(LOG_WARNING, _("unknown interface %s in
> bridge-interface"), ifr.ifr_name);
>                  return;
>                }
>              else
>                {
>                  strncpy(ifr.ifr_name,  bridge->iface, IF_NAMESIZE);
>                  break;
>                }
>            }
>
>        if (alias)
>          break;
>
>
>
> which is wrong: the log message should be logging bridge->iface, not
> ifr.ifr_name, but at least it does warn you when you do
>
> --bridge-interface = somenonexistinginterface, alias
>
> and therefore it's throwing away you DHCP packets.
>
> The DHCPv6 code should implement that warning too.
>
> I've been threatening a 2.73 release for so long that people have
> stopped believing me, but the ducks do seem to be almost in a row, so
> getting this finished soon would be good, if it's to go in.

Many thanks, Simon, I'll work on these remaining points immediately. 
Would you prefer the deltas for them to be as additional patches, or to 
have the patch set regenerated with the required deltas incorporated at 
the appropriate places?

Regards,
	Neil

> Cheers,
>
> Simon.
>
>
>>
>> Many thanks,
>>      Neil
>>
>>
>>
>> On 13/10/14 17:45, Simon Kelley wrote:
>>> On 07/10/14 18:28, Neil Jerram wrote:
>>>>> On 03/10/14 16:54, Neil Jerram wrote:
>>>>
>>>>>> I'd like to propose the attached patches, which extend the aliasing
>>>>>> concept of the --bridge-interface option to DHCPv6 and Router
>>>>>> Advertisement processing.  [...]
>>>>>
>>>>> A query: the semantics you've provided for DHCPv6 are subtly different
>>>>> than those that exist for DHCPv4.
>>>>>
>>>>> In DHCPv4, the alias is absolute, eg
>>>>>
>>>>> bridge-interface=eth0,tap0
>>>>>
>>>>> when a packet arrives at tap0, then it is processed as if it arrived at
>>>>> eth0, any addresses associated with tap0 are ignored.
>>>>>
>>>>> With this patch, for DHCPv6, dnsmasq first attempts to find a
>>>>> DHCP-context by using the addresses associated with tap0, and only if
>>>>> that fails does it use the addresses associated with eth0.
>>>>
>>>> Indeed, good catch - I had missed that.
>>>>
>>>>> If this is required behaviour, I guess we should document the
>>>>> difference
>>>>> in the v4 and v6 cases. If it's like that by chance, we should think
>>>>> about if providing the same behaviour in both cases might be
>>>>> preferable.
>>>>
>>>> It isn’t required behaviour.  At least, for the compute host scenario
>>>> that I am interested in, the alias interfaces will never have any IP
>>>> addressing or contexts of their own, and also the aliased interface -
>>>> i.e. the one that _does_ have the DHCP context - will never receive a
>>>> packet directly itself.  Therefore, for my purposes, it would be fine
>>>> to align the DHCPv6 behaviour precisely with the v4 behaviour.
>>>>
>>>> Logically I think the same should also apply to solicited RA
>>>> processing, i.e. in the ND_ROUTER_SOLICIT block of icmp6_packet.
>>>> Would you agree?
>>>
>>> Yes, certainly.
>>>
>>>>
>>>> Finally, I guess I should also update the "One form of bridging ..."
>>>> comment in dhcp_packet, and the man page text on --bridge-interfaces,
>>>> to mention my scenario in addition to the BSD one.
>>>
>>> Yes, that's well out-of-date.
>>>>
>>>> If that all sounds good to you, I'm happy to work on updating the
>>>> patches - please let me know what you think.
>>>
>>> Please do. Happy to have this.
>>>
>>>
>>> Cheers,
>>>
>>> Simon.
>>>
>>>>
>>>> Regards,
>>>>           Neil
>>>>
>>>>
>>>
>