Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
Thanks Simon! On 10/06/15 22:49, Simon Kelley wrote: On 10/06/15 10:57, Neil Jerram wrote: Alternatively, here is the whole patch set again, regenerated so as to incorporate those deltas at the appropriate places. Many thanks for your time looking at these enhancements. Regards, Neil Many thanks. Patches applied, and 2.73rc10 generated. Unless anyone can give me a reason why not, this will become 2.73 in a couple of days. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
On 10/06/15 10:57, Neil Jerram wrote: > Alternatively, here is the whole patch set again, regenerated so as to > incorporate those deltas at the appropriate places. > > Many thanks for your time looking at these enhancements. > > Regards, > Neil > > Many thanks. Patches applied, and 2.73rc10 generated. Unless anyone can give me a reason why not, this will become 2.73 in a couple of days. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
On 10/06/15 10:15, Neil Jerram wrote:
On 09/06/15 22:11, Simon Kelley wrote:
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?
Here are the deltas to address those points.
Regards,
Neil
>From 67793b1936c99bd55241b7db90de74c88c463e60 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 10 Jun 2015 10:20:14 +0100
Subject: [PATCH 6/9] Remove stray exclamation mark in radv.c comment
---
src/radv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/radv.c b/src/radv.c
index 532b698..39f1e92 100644
--- a/src/radv.c
+++ b/src/radv.c
@@ -826,7 +826,7 @@ time_t periodic_ra(time_t now)
free(aparam.alias_ifs);
}
-/* The source interface! can only appear in at most
+/* The source interface can only appear in at most
one --bridge-interface. */
break;
}
--
2.1.4
>From 21ede1039470657f4e0ae0a7161f629604cc8f38 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 10 Jun 2015 10:25:42 +0100
Subject: [PATCH 7/9] dhcp.c: Log correct bridge interface name when
if_nametoindex fails for it
---
src/dhcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/dhcp.c b/src/dhcp.c
index daca6de..a2aa898 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -237,7 +237,7 @@ void dhcp_packet(time_t now, int pxe_fd)
{
if (!(iface_index = if_nametoindex(bridge->iface)))
{
- my_syslog(LOG_WARNING, _("unknown interface %s in bridge-interface"), ifr.ifr_name);
+ my_syslog(LOG_WARNING, _("unknown interface %s in bridge-interface"), bridge->iface);
return;
}
else
--
2.1.4
>From ac901e6fe7864e4e67c8199609d6e9c0c39620cf Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 10 Jun 2015 10:42:50 +0100
Subject: [PATCH 8/9] dhcp6.c: Warn if if_nametoindex fails for bridge
interface name
---
src/dhcp6.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/dhcp6.c b/src/dhcp6.c
index 9683170..8286ff4 100644
--- a/src/dhcp6.c
+++ b/src/dhcp6.c
@@ -174,6 +174,13 @@ void dhcp6_packet(time_t now)
if (wildcard_matchn(alias->iface, ifr.ifr_name, IF_NAMESIZE))
{
parm.ind = if_nametoindex(bridge->iface);
+ if (!parm.ind)
+ {
+ my_syslog(MS_DHCP | LOG_WARNING,
+ _("unknown interface %s in bridge-interface"),
+ bridge->iface);
+ return;
+ }
break;
}
if (alias)
--
2.1.4
>From 594e4ceb58e533b3b31a4e983cfcd9937271cd70 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 10 Jun 2015 10:43:54 +0100
Subject: [PATCH 9/9] dhcp.c: Add MS_DHCP to log about unrecognized bridge
interface name
---
src/dhcp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/dhcp.c b/src/dhcp.c
index a2aa898..e6fceb1 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -237,7 +237,9 @@ void dhcp_packet(time_t now, int pxe_fd)
{
if (!(iface_index = if_nametoindex(bridge->iface)))
{
- my_syslog(LOG_WARNING, _("unknown interface %s in bridge-interface"), bridge->iface);
+ my_syslog(MS_DHCP | LOG_WARNING,
+ _("unknown interface %s in bridge-interface"),
+ bridge->iface);
return;
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
On 10/06/15 10:47, Neil Jerram wrote:
On 10/06/15 10:15, Neil Jerram wrote:
On 09/06/15 22:11, Simon Kelley wrote:
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?
Here are the deltas to address those points.
Alternatively, here is the whole patch set again, regenerated so as to
incorporate those deltas at the appropriate places.
Many thanks for your time looking at these enhancements.
Regards,
Neil
>From c5748da52f2d789637d50f899862f0a83f385ea2 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 10 Jun 2015 10:25:42 +0100
Subject: [PATCH 1/7] dhcp.c: Log correct bridge interface name when
if_nametoindex fails for it
---
src/dhcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/dhcp.c b/src/dhcp.c
index f1f43f8..ef976e8 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -236,7 +236,7 @@ void dhcp_packet(time_t now, int pxe_fd)
{
if (!(iface_index = if_nametoindex(bridge->iface)))
{
- my_syslog(LOG_WARNING, _("unknown interface %s in bridge-interface"), ifr.ifr_name);
+ my_syslog(LOG_WARNING, _("unknown interface %s in bridge-interface"), bridge->iface);
return;
}
else
--
2.1.4
>From 1ee8223a1d26cda1ecbdc421f530ceb594592899 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 10 Jun 2015 10:43:54 +0100
Subject: [PATCH 2/7] dhcp.c: Add MS_DHCP to log about unrecognized bridge
interface name
---
src/dhcp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/dhcp.c b/src/dhcp.c
index ef976e8..eb1ea81 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -236,7 +236,9 @@ void dhcp_packet(time_t now, int pxe_fd)
{
if (!(iface_index = if_nametoindex(bridge->iface)))
{
- my_syslog(LOG_WARNING, _("unknown interface %s in bridge-interface"), bridge->iface);
+ my_syslog(MS_DHCP | LOG_WARNING,
+ _("unknown interface %s in bridge-interface"),
+ bridge->iface);
return;
}
else
--
2.1.4
>From 138dd675f9bbfa87894af3c9d83ba25960cdf18d Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Mon, 15 Sep 2014 14:45:01 +0100
Subject: [PATCH 3/7] Implement aliasing idea (per --bridge-interfaces) for
DHCPv6 as well as for v4
---
src/dhcp6.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/src/dhcp6.c b/src/dhcp6.c
index ee2aa5d..4c60c6e 100644
--- a/src/dhcp6.c
+++ b/src/dhcp6.c
@@ -144,6 +144,8 @@ void dhcp6_packet(time_t now)
if ((port = relay_reply6(&from, sz, ifr.ifr_name)) == 0)
{
+ struct dhcp_bridge *bridge, *alias;
+
for (tmp = daemon->if_except; tmp; tmp = tmp->next)
if (tmp->name && wildcard_match(tmp->name, ifr.ifr_name))
return;
@@ -160,6 +162,30 @@ void dhcp6_packet(time_t now)
memset(&parm.fallback, 0, IN6ADDRSZ);
memset(&parm.ll_addr, 0, IN6ADDRSZ);
memset(&parm.ula_addr, 0, IN6ADDRSZ);
+
+ /* If the interface on which the DHCPv6 request was received is
+ an alias of some other interface (as specified by the
+ --bridge-interfaces option), change parm.ind so that we look
+ for DHCPv6 contexts associated with the aliased interface
+ instead of with the aliasing one. */
+ for (bridge = daemon->bridges
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
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.
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
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
>>>
>>>
>>
_
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
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?
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
>From db3a9ba6b21694b9583f87e948d9de722004697c Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Mon, 15 Sep 2014 14:45:01 +0100
Subject: [PATCH 1/5] Implement aliasing idea (per --bridge-interfaces) for
DHCPv6 as well as for v4
---
src/dhcp6.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/src/dhcp6.c b/src/dhcp6.c
index ee2aa5d..e803f35 100644
--- a/src/dhcp6.c
+++ b/src/dhcp6.c
@@ -144,6 +144,8 @@ void dhcp6_packet(time_t now)
if ((port = relay_reply6(&from, sz, ifr.ifr_name)) == 0)
{
+ struct dhcp_bridge *bridge, *alias;
+
for (tmp = daemon->if_except; tmp; tmp = tmp->next)
if (tmp->name && wildcard_match(tmp->name, ifr.ifr_name))
return;
@@ -160,6 +162,23 @@ void dhcp6_packet(time_t now)
memset(&parm.fallback, 0, IN6ADDRSZ);
memset(&parm.ll_addr, 0, IN6ADDRSZ);
memset(&parm.ula_addr, 0, IN6ADDRSZ);
+
+ /* If the interface on which the DHCPv6 request was received is
+ an alias of some other interface (as specified by the
+ --bridge-interfaces option), change parm.ind so that we look
+ for DHCPv6 contexts associated with the aliased interface
+ instead of with the aliasing one. */
+ 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))
+ {
+ parm.ind = if_nametoindex(bridge->iface);
+ break;
+ }
+ if (alias)
+ break;
+ }
for (context = daemon->dhcp6; context; context = context->next)
if (IN6_IS_ADDR_UNSPECIFIED(&context->start6) && context->prefix == 0)
@@ -208,7 +227,7 @@ void dhcp6_packet(time_t now)
/* May have configured relay, but not DHCP server */
if (!daemon->doing_dhcp6)
return;
-
+
lease_prune(NULL, now); /* lose any expired leases */
port = dhcp6_reply(parm.current, if_index, ifr.ifr_name, &parm.fallback,
--
2.1.4
>From f0b091a8b0b6bb7f625ddaf5b676f60dd26099dc Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Mon, 15 Sep 2014 14:46:34 +0100
Subject: [PATCH 2/5] Allow
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
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 > > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
> 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? 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. If that all sounds good to you, I'm happy to work on updating the patches - please let me know what you think. Regards, Neil ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
On 03/10/14 16:54, Neil Jerram wrote: > Hi all, > > I'd like to propose the attached patches, which extend the aliasing > concept of the --bridge-interface option to DHCPv6 and Router > Advertisement processing. Prior to these patches, the effect of the > --bridge-interface option is limited to DHCPv4. I think it's a > natural extension for it to apply to DHCPv6 and RAs as well. > > I should give a little background about the scenario motivating this. > As with my previous patch [1, 2], the scenario is that of a compute > host providing connectivity and DHCP for a number of VMs or > containers, where the data into and out of the TAP (or veth) > interfaces to those VMs/containers is routed rather than being > bridged. In this scenario, the desire is to provide DHCPv4, DHCPv6 > and Router Advertisements to all the TAP/veth interfaces, from a DHCP/RA > context specification on some other interface. > > [1] > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q2/008600.html > [2] > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=70772c909199ad6701dc25593bc185938fa4cd23 > > I hope that makes sense. Please can you let me know what you think, > including whether these patches are suitable for dnsmasq? > > Many thanks, > Neil > 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. 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. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
Hi all, I'd like to propose the attached patches, which extend the aliasing concept of the --bridge-interface option to DHCPv6 and Router Advertisement processing. Prior to these patches, the effect of the --bridge-interface option is limited to DHCPv4. I think it's a natural extension for it to apply to DHCPv6 and RAs as well. I should give a little background about the scenario motivating this. As with my previous patch [1, 2], the scenario is that of a compute host providing connectivity and DHCP for a number of VMs or containers, where the data into and out of the TAP (or veth) interfaces to those VMs/containers is routed rather than being bridged. In this scenario, the desire is to provide DHCPv4, DHCPv6 and Router Advertisements to all the TAP/veth interfaces, from a DHCP/RA context specification on some other interface. [1] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q2/008600.html [2] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=70772c909199ad6701dc25593bc185938fa4cd23 I hope that makes sense. Please can you let me know what you think, including whether these patches are suitable for dnsmasq? Many thanks, Neil 0001-Implement-aliasing-idea-per-bridge-interfaces-for-DH.patch Description: 0001-Implement-aliasing-idea-per-bridge-interfaces-for-DH.patch 0002-Allow-configuration-of-on-link-L-bit-in-Router-Adver.patch Description: 0002-Allow-configuration-of-on-link-L-bit-in-Router-Adver.patch 0003-Implement-aliasing-idea-per-bridge-interfaces-for-so.patch Description: 0003-Implement-aliasing-idea-per-bridge-interfaces-for-so.patch 0004-Implement-aliasing-for-unsolicited-router-advertisem.patch Description: 0004-Implement-aliasing-for-unsolicited-router-advertisem.patch 0005-Documentation-for-IPv6-enhancements.patch Description: 0005-Documentation-for-IPv6-enhancements.patch ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
