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

[Simon Kelley]

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.

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
>>>
>>>
>>