gre: Fix regressions in IPv6 link-local address generation.
Subsystems (4)
v2 cover gre: Fix regressions in IPv6 link-local address generation.
IPv6 link-local address generation has some special cases for GRE devices. This has led to several regressions in the past, and some of them are still not fixed. This series fixes the remaining problems, like the ipv6.conf.<dev>.addr_gen_mode sysctl being ignored and the router discovery process not being started (see details in patch 1).
To avoid any further regressions, patch 2 adds selftests covering IPv4 and IPv6 gre/gretap devices with all combinations of currently supported addr_gen_mode values.
v2: Add Makefile entry for the new selftest (patch 2).
Guillaume Nault (2):
gre: Fix IPv6 link-local address generation.
selftests: Add IPv6 link-local address generation tests for GRE
devices.
net/ipv6/addrconf.c | 15 +- tools/testing/selftests/net/Makefile | 1 + .../testing/selftests/net/gre_ipv6_lladdr.sh | 227 ++++++++++++++++++ 3 files changed, 237 insertions(+), 6 deletions(-) create mode 100755 tools/testing/selftests/net/gre_ipv6_lladdr.sh
Signature · 1 line
2.39.2
PATCH v2 1/2 gre: Fix IPv6 link-local address generation.
Use addrconf_addr_gen() to generate IPv6 link-local addresses on GRE devices in most cases and fall back to using add_v4_addrs() only in case the GRE configuration is incompatible with addrconf_addr_gen().
GRE used to use addrconf_addr_gen() until commit e5dd729460ca ("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL address") restricted this use to gretap devices and created add_v4_addrs() (borrowed from SIT) for non-Ethernet GRE ones.
The original problem came when commit 9af28511be10 ("addrconf: refuse isatap eui64 for INADDR_ANY") made __ipv6_isatap_ifid() fail when its addr parameter was 0. The commit says that this would create an invalid address, however, I couldn't find any RFC saying that the generated interface identifier would be wrong. Anyway, since plain gre devices pass their local tunnel address to __ipv6_isatap_ifid(), that commit broke their IPv6 link-local address generation when the local address was unspecified.
Then commit e5dd729460ca ("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL address") tried to fix that case by defining add_v4_addrs() and calling it to generated the IPv6 link-local address instead of using addrconf_addr_gen() (appart for gretap devices which would still use the regular addrconf_addr_gen(), since they have a MAC address).
That broke several use cases because add_v4_addrs() isn't properly integrated into the rest of IPv6 Neighbor Discovery code. Several of these shortcomings have been fixed over time, but add_v4_addrs() remains broken on several aspects. In particular, it doesn't send any Router Sollicitations, so the SLAAC process doesn't start until the interface receives a Router Advertisement. Also, add_v4_addrs() mostly ignores the address generation mode of the interface (/proc/sys/net/ipv6/conf/*/addr_gen_mode), thus breaking the IN6_ADDR_GEN_MODE_RANDOM and IN6_ADDR_GEN_MODE_STABLE_PRIVACY cases.
Fix all this by reverting to addrconf_addr_gen() in all cases but the very specific one that remains incompatible.
Fix the situation by using add_v4_addrs() only in the specific scenario where normal method would fail. That is, for interfaces that have all of the following characteristics:
* transport IP packets directly, not Ethernet (that is, not gretap),
* run over IPv4,
* tunnel endpoint is INADDR_ANY (that is, 0),
* device address generation mode is EUI64.
In all other cases, revert back to the regular addrconf_addr_gen().
Also, remove the special case for ip6gre interfaces in add_v4_addrs(), since ip6gre devices now always use addrconf_addr_gen() instead.
--- net/ipv6/addrconf.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
net/ipv6/addrconf.c +9 -6
@@ -3209,16 +3209,13 @@ static void add_v4_addrs(struct inet6_dev *idev)struct in6_addr addr;struct net_device *dev;struct net *net =dev_net (idev->dev); -int scope, plen, offset =0 ; +int scope, plen;u32 pflags =0 ;ASSERT_RTNL ();memset (&addr,0 ,sizeof (struct in6_addr )); -/* in case of IP6GRE the dev_addr is an IPv6 and therefore we use only the last 4 bytes */ -if (idev->dev->addr_len ==sizeof (struct in6_addr )) - offset =sizeof (struct in6_addr ) -4 ; -memcpy (&addr.s6_addr32[3 ], idev->dev->dev_addr + offset,4 ); +memcpy (&addr.s6_addr32[3 ], idev->dev->dev_addr,4 );if (!(idev->dev->flags &IFF_POINTOPOINT ) && idev->dev->type ==ARPHRD_SIT ) { scope = IPV6_ADDR_COMPATv4;
@@ -3529,7 +3526,13 @@ static void addrconf_gre_config(struct net_device *dev)return ; } -if (dev->type ==ARPHRD_ETHER ) { +/* Generate the IPv6 link-local address using addrconf_addr_gen(), +* unless we have an IPv4 GRE device not bound to an IP address and +* which is in EUI64 mode (as __ipv6_isatap_ifid() would fail in this +* case). Such devices fall back to add_v4_addrs() instead. +*/ +if (!(dev->type ==ARPHRD_IPGRE && *(__be32 *)dev->dev_addr ==0 && + idev->cnf.addr_gen_mode ==IN6_ADDR_GEN_MODE_EUI64 )) {addrconf_addr_gen (idev, true);return ; }
Signature · 1 line
2.39.2
Re: [PATCH net v2 1/2] gre: Fix IPv6 link-local address generation.
Quoted 7 lines · Guillaume Nault
Use
addrconf_addr_gen()to generate IPv6 link-local addresses on GRE devices in most cases and fall back to usingadd_v4_addrs()only in case the GRE configuration is incompatible withaddrconf_addr_gen().GRE used to use
addrconf_addr_gen()until commite5dd729460ca("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL address") restricted this use to gretap devices and created
It's not always clear throughout the commit message to which devices you are referring to. For example, here, by "gretap" you mean both "gretap" and "ip6gretap", no?
BTW, I believe the check against 'ARPHRD_ETHER' in addrconf_gre_config() is dead code. addrconf_gre_config() is only called for ARPHRD_IP{,6}GRE devices.
Quoted 10 lines
add_v4_addrs()(borrowed from SIT) for non-Ethernet GRE ones.The original problem came when commit
9af28511be10("addrconf: refuse isatap eui64 forINADDR_ANY") made__ipv6_isatap_ifid()fail when its addr parameter was 0. The commit says that this would create an invalid address, however, I couldn't find any RFC saying that the generated interface identifier would be wrong. Anyway, since plain gre devices pass their local tunnel address to__ipv6_isatap_ifid(), that commit broke their IPv6 link-local address generation when the local address was unspecified.
By "plain gre devices" you mean "ipgre"? Because addrconf_ifid_ip6tnl() is called for "ip6gre" and it doesn't fail, unlike __ipv6_isatap_ifid().
Quoted 4 lines
Then commit
e5dd729460ca("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL address") tried to fix that case by definingadd_v4_addrs()and calling it to generated the IPv6 link-local
s/generated/generate/
Quoted 1 line
address instead of using
addrconf_addr_gen()(appart for gretap devices
s/appart/apart/
Quoted 2 lines
which would still use the regular
addrconf_addr_gen(), since they have a MAC address).
Assuming what I wrote is correct, I'm not sure why e5dd729460ca didn't restrict the fix to "ipgre" and applied it to "ip6gre" as well.
Quoted 58 lines
That broke several use cases because
add_v4_addrs()isn't properly integrated into the rest of IPv6 Neighbor Discovery code. Several of these shortcomings have been fixed over time, butadd_v4_addrs()remains broken on several aspects. In particular, it doesn't send any Router Sollicitations, so the SLAAC process doesn't start until the interface receives a Router Advertisement. Also,add_v4_addrs()mostly ignores the address generation mode of the interface (/proc/sys/net/ipv6/conf/*/addr_gen_mode), thus breaking theIN6_ADDR_GEN_MODE_RANDOMandIN6_ADDR_GEN_MODE_STABLE_PRIVACYcases.Fix all this by reverting to
addrconf_addr_gen()in all cases but the very specific one that remains incompatible.Fix the situation by using
add_v4_addrs()only in the specific scenario where normal method would fail. That is, for interfaces that have all of the following characteristics:* transport IP packets directly, not Ethernet (that is, not gretap),
* run over IPv4,
* tunnel endpoint isINADDR_ANY(that is, 0),
* device address generation mode is EUI64.In all other cases, revert back to the regular
addrconf_addr_gen().Also, remove the special case for ip6gre interfaces in
add_v4_addrs(), since ip6gre devices now always useaddrconf_addr_gen()instead.Fixes e5dd729460ca ("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL address")Signed-off-by Guillaume Nault <[email protected]>--- net/ipv6/addrconf.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)net/ipv6/addrconf.c +2
-5@@ -3209,16 +3209,13 @@ static void add_v4_addrs(struct inet6_dev *idev)struct in6_addr addr;struct net_device *dev;struct net *net =dev_net (idev->dev); -int scope, plen, offset =0 ; +int scope, plen;u32 pflags =0 ;ASSERT_RTNL ();memset (&addr,0 ,sizeof (struct in6_addr )); -/* in case of IP6GRE the dev_addr is an IPv6 and therefore we use only the last 4 bytes */ -if (idev->dev->addr_len ==sizeof (struct in6_addr )) - offset =sizeof (struct in6_addr ) -4 ; -memcpy (&addr.s6_addr32[3 ], idev->dev->dev_addr + offset,4 ); +memcpy (&addr.s6_addr32[3 ], idev->dev->dev_addr,4 );if (!(idev->dev->flags &IFF_POINTOPOINT ) && idev->dev->type ==ARPHRD_SIT ) { scope = IPV6_ADDR_COMPATv4;
net/ipv6/addrconf.c static void addrconf_gre_config(struct net_device *dev) · line 3534
Quoted 10 lines
net/ipv6/addrconf.c +6
-1@@ -3529,7 +3526,13 @@ static void addrconf_gre_config(struct net_device *dev)return ; } -if (dev->type ==ARPHRD_ETHER ) { +/* Generate the IPv6 link-local address using addrconf_addr_gen(), +* unless we have an IPv4 GRE device not bound to an IP address and +* which is in EUI64 mode (as __ipv6_isatap_ifid() would fail in this +* case). Such devices fall back to add_v4_addrs() instead. +*/ + if (!(dev->type == ARPHRD_IPGRE && *(__be32 *)dev->dev_addr == 0 &&
Doesn't this mean that the 'ARPHRD_IP6GRE' case (and the 'CONFIG_IPV6_GRE' checks) can be removed from addrconf_init_auto_addrs()? That is, only call addrconf_gre_config() for "ipgre", but not for "ip6gre".
Quoted 8 lines
net/ipv6/addrconf.c +1
-0+ idev->cnf.addr_gen_mode == IN6_ADDR_GEN_MODE_EUI64)) {addrconf_addr_gen (idev, true);return ; }Signature · 1 line
2.39.2
Re: [PATCH net v2 1/2] gre: Fix IPv6 link-local address generation.
Quoted 11 lines · Ido Schimmel
Quoted 7 lines · Guillaume Nault
Use
addrconf_addr_gen()to generate IPv6 link-local addresses on GRE devices in most cases and fall back to usingadd_v4_addrs()only in case the GRE configuration is incompatible withaddrconf_addr_gen().GRE used to use
addrconf_addr_gen()until commite5dd729460ca("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL address") restricted this use to gretap devices and createdIt's not always clear throughout the commit message to which devices you are referring to.
Yes, that's a problem I had when writing the commit message: I couldn't find a proper way to name the different GRE device types unambiguously.
By reusing the device types of "ip link" we don't know if "gre" refers to all GRE types or if it's only for IPv4 encapsulation. But using the ARPHRD_* types wouldn't help, as that wouldn't allow to distinguish between gretap and ip6gretap.
Maybe the following terms would be clearer:
'ip4gre', 'ip4gretap', 'ip6gre', 'ip6gretap' (and potentially 'ipXgre' and 'ipXgretap' when considering both the IPv4 and IPv6 tunnel versions). Would you find these terms clearer?
Quoted 2 lines
For example, here, by "gretap" you mean both "gretap" and "ip6gretap", no?
Yes.
Quoted 3 lines
BTW, I believe the check against '
ARPHRD_ETHER' inaddrconf_gre_config()is dead code.addrconf_gre_config()is only called for ARPHRD_IP{,6}GRE devices.
Yes, that was dead code. But I'm reusing that condition to minimise code changes so to make the fix simpler. Do you mean I should write explicitely, somewhere, that it was dead code but isn't anymore?
Quoted 11 lines
Quoted 10 lines
add_v4_addrs()(borrowed from SIT) for non-Ethernet GRE ones.The original problem came when commit
9af28511be10("addrconf: refuse isatap eui64 forINADDR_ANY") made__ipv6_isatap_ifid()fail when its addr parameter was 0. The commit says that this would create an invalid address, however, I couldn't find any RFC saying that the generated interface identifier would be wrong. Anyway, since plain gre devices pass their local tunnel address to__ipv6_isatap_ifid(), that commit broke their IPv6 link-local address generation when the local address was unspecified.
Quoted 2 lines
By "plain gre devices" you mean "ipgre"? Because
addrconf_ifid_ip6tnl()is called for "ip6gre" and it doesn't fail, unlike__ipv6_isatap_ifid().
Exactly. I tried to use the "plain" adjective to say that's the kind of device you get with the "gre" keyword in "ip link".
Quoted 9 lines
Quoted 3 lines
Then commit
e5dd729460ca("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL address") tried to fix that case by definingadd_v4_addrs()and calling it to generated the IPv6 link-locals/generated/generate/
Quoted 1 line
address instead of using
addrconf_addr_gen()(appart for gretap devicess/appart/apart/
Will fix both.
Quoted 5 lines
Quoted 2 lines
which would still use the regular
addrconf_addr_gen(), since they have a MAC address).Assuming what I wrote is correct, I'm not sure why
e5dd729460cadidn't restrict the fix to "ipgre" and applied it to "ip6gre" as well.
I asked myself the same question. Antonio might have an answer to this. But in my understanding the changes brought by e5dd729460ca were much too broad.
Quoted 4 lines
Quoted 4 lines
net/ipv6/addrconf.c +3
-1-if (dev->type ==ARPHRD_ETHER ) { +/* Generate the IPv6 link-local address using addrconf_addr_gen(), +* unless we have an IPv4 GRE device not bound to an IP address and +* which is in EUI64 mode (as __ipv6_isatap_ifid() would fail in this
Quoted 8 lines
net/ipv6/addrconf.c static void addrconf_gre_config(struct net_device *dev) · line 3534
Quoted 3 lines
net/ipv6/addrconf.c +3
-0+* case). Such devices fall back to add_v4_addrs() instead. +*/ + if (!(dev->type == ARPHRD_IPGRE && *(__be32 *)dev->dev_addr == 0 &&Doesn't this mean that the '
ARPHRD_IP6GRE' case (and the 'CONFIG_IPV6_GRE' checks) can be removed fromaddrconf_init_auto_addrs()? That is, only calladdrconf_gre_config()for "ipgre", but not for "ip6gre".
Yes. But I didn't want to do that here, to keep the fix as simple as possible. Because that'd mean we'd also have to add a "(dev->type != ARPHRD_IP6GRE)" condition in the test at the beginning of addrconf_dev_config(), and I feel that'd be a distraction from the core of the patch. So I prefer to do that in net-next.
Quoted 9 lines
Quoted 8 lines
net/ipv6/addrconf.c +1
-0+ idev->cnf.addr_gen_mode == IN6_ADDR_GEN_MODE_EUI64)) {addrconf_addr_gen (idev, true);return ; }Signature · 1 line
2.39.2
Thanks a lot for your review.
Re: [PATCH net v2 1/2] gre: Fix IPv6 link-local address generation.
Quoted 13 lines · Guillaume Nault
Quoted 11 lines · Ido Schimmel
Quoted 7 lines · Guillaume Nault
Use
addrconf_addr_gen()to generate IPv6 link-local addresses on GRE devices in most cases and fall back to usingadd_v4_addrs()only in case the GRE configuration is incompatible withaddrconf_addr_gen().GRE used to use
addrconf_addr_gen()until commite5dd729460ca("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL address") restricted this use to gretap devices and createdIt's not always clear throughout the commit message to which devices you are referring to.
Quoted 7 lines
Yes, that's a problem I had when writing the commit message: I couldn't find a proper way to name the different GRE device types unambiguously.
By reusing the device types of "ip link" we don't know if "gre" refers to all GRE types or if it's only for IPv4 encapsulation. But using the ARPHRD_* types wouldn't help, as that wouldn't allow to distinguish between gretap and ip6gretap.
Right.
Quoted 5 lines
Maybe the following terms would be clearer:
'ip4gre', 'ip4gretap', 'ip6gre', 'ip6gretap' (and potentially 'ipXgre' and 'ipXgretap' when considering both the IPv4 and IPv6 tunnel versions). Would you find these terms clearer?
I'm fine with the above, but I also think that as long as "ip link" types (e.g., 'gre', 'ip6gre') are consistently used throughout the commit message, it should be clear which devices the commit message refers to. Whatever you prefer.
Quoted 6 lines
Quoted 3 lines
For example, here, by "gretap" you mean both "gretap" and "ip6gretap", no?
Yes.
Quoted 7 lines
Quoted 3 lines
BTW, I believe the check against '
ARPHRD_ETHER' inaddrconf_gre_config()is dead code.addrconf_gre_config()is only called for ARPHRD_IP{,6}GRE devices.Yes, that was dead code. But I'm reusing that condition to minimise code changes so to make the fix simpler. Do you mean I should write explicitely, somewhere, that it was dead code but isn't anymore?
No, it's fine as-is. I made the comment while reading the commit message and looking at the unpatched code and only later when I checked the patch I noticed that you already took care of it :)
Quoted 33 lines
Quoted 12 lines
Quoted 11 lines
add_v4_addrs()(borrowed from SIT) for non-Ethernet GRE ones.The original problem came when commit
9af28511be10("addrconf: refuse isatap eui64 forINADDR_ANY") made__ipv6_isatap_ifid()fail when its addr parameter was 0. The commit says that this would create an invalid address, however, I couldn't find any RFC saying that the generated interface identifier would be wrong. Anyway, since plain gre devices pass their local tunnel address to__ipv6_isatap_ifid(), that commit broke their IPv6 link-local address generation when the local address was unspecified.Quoted 2 lines
By "plain gre devices" you mean "ipgre"? Because
addrconf_ifid_ip6tnl()is called for "ip6gre" and it doesn't fail, unlike__ipv6_isatap_ifid().Exactly. I tried to use the "plain" adjective to say that's the kind of device you get with the "gre" keyword in "ip link".
Quoted 9 lines
Quoted 3 lines
Then commit
e5dd729460ca("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL address") tried to fix that case by definingadd_v4_addrs()and calling it to generated the IPv6 link-locals/generated/generate/
Quoted 1 line
address instead of using
addrconf_addr_gen()(appart for gretap devicess/appart/apart/
Will fix both.
Quoted 3 lines
Quoted 2 lines
which would still use the regular
addrconf_addr_gen(), since they have a MAC address).
Quoted 6 lines
Quoted 2 lines
Assuming what I wrote is correct, I'm not sure why
e5dd729460cadidn't restrict the fix to "ipgre" and applied it to "ip6gre" as well.I asked myself the same question. Antonio might have an answer to this. But in my understanding the changes brought by
e5dd729460cawere much too broad.
I agree.
Quoted 14 lines
Quoted 13 lines
net/ipv6/addrconf.c static void addrconf_gre_config(struct net_device *dev) · line 3534
Quoted 8 lines
net/ipv6/addrconf.c +6
-1-if (dev->type ==ARPHRD_ETHER ) { +/* Generate the IPv6 link-local address using addrconf_addr_gen(), +* unless we have an IPv4 GRE device not bound to an IP address and +* which is in EUI64 mode (as __ipv6_isatap_ifid() would fail in this +* case). Such devices fall back to add_v4_addrs() instead. +*/ + if (!(dev->type == ARPHRD_IPGRE && *(__be32 *)dev->dev_addr == 0 &&Doesn't this mean that the '
ARPHRD_IP6GRE' case (and the 'CONFIG_IPV6_GRE' checks) can be removed fromaddrconf_init_auto_addrs()? That is, only calladdrconf_gre_config()for "ipgre", but not for "ip6gre".
Quoted 5 lines
Yes. But I didn't want to do that here, to keep the fix as simple as possible. Because that'd mean we'd also have to add a "(
dev->type!=ARPHRD_IP6GRE)" condition in the test at the beginning ofaddrconf_dev_config(), and I feel that'd be a distraction from the core of the patch. So I prefer to do that in net-next.
Fine by me. Thanks!
Re: [PATCH net v2 1/2] gre: Fix IPv6 link-local address generation.
Quoted 19 lines · Ido Schimmel
Quoted 10 lines · Guillaume Nault
Quoted 9 lines · Ido Schimmel
Quoted 7 lines · Guillaume Nault
Use
addrconf_addr_gen()to generate IPv6 link-local addresses on GRE devices in most cases and fall back to usingadd_v4_addrs()only in case the GRE configuration is incompatible withaddrconf_addr_gen().GRE used to use
addrconf_addr_gen()until commite5dd729460ca("ip/ip6_gre: use the same logic as SIT interfaces when computing v6LL address") restricted this use to gretap devices and createdQuoted 7 lines
Quoted 2 lines
It's not always clear throughout the commit message to which devices you are referring to.
Maybe the following terms would be clearer:
'ip4gre', 'ip4gretap', 'ip6gre', 'ip6gretap' (and potentially 'ipXgre' and 'ipXgretap' when considering both the IPv4 and IPv6 tunnel versions). Would you find these terms clearer?
Quoted 4 lines
I'm fine with the above, but I also think that as long as "ip link" types (e.g., 'gre', 'ip6gre') are consistently used throughout the commit message, it should be clear which devices the commit message refers to. Whatever you prefer.
I've finally opted for reusing "ip link" types, plus a bit of rewording to remove potential ambiguities.
PATCH v2 2/2 selftests: Add IPv6 link-local address generation tests for GRE devices.
In reply to Guillaume NaultGRE devices have their special code for IPv6 link-local address generation that has been the source of several regressions in the past.
Add selftest to check that all gre, ip6gre, gretap and ip6gretap get an IPv6 link-link local address in accordance with the net.ipv6.conf.<dev>.addr_gen_mode sysctl.
---
v2: Add selftest to Makefile.
tools/testing/selftests/net/Makefile | 1 + .../testing/selftests/net/gre_ipv6_lladdr.sh | 227 ++++++++++++++++++ 2 files changed, 228 insertions(+) create mode 100755 tools/testing/selftests/net/gre_ipv6_lladdr.sh
tools/testing/selftests/net/Makefile +1 -0
@@ -31,6 +31,7 @@ TEST_PROGS += veth.sh TEST_PROGS += ioam6.sh TEST_PROGS += gro.sh TEST_PROGS += gre_gso.sh +TEST_PROGS += gre_ipv6_lladdr.sh TEST_PROGS += cmsg_so_mark.sh TEST_PROGS += cmsg_so_priority.sh TEST_PROGS += cmsg_time.sh cmsg_ipv6.sh
tools/testing/selftests/net/gre_ipv6_lladdr.sh new file +227 -0
227 lines not on this page · raw message
Signature · 1 line
2.39.2
Re: [PATCH net v2 2/2] selftests: Add IPv6 link-local address generation tests for GRE devices.
Quoted 8 lines · Guillaume Nault
GRE devices have their special code for IPv6 link-local address generation that has been the source of several regressions in the past.
Add selftest to check that all gre, ip6gre, gretap and ip6gretap get an IPv6 link-link local address in accordance with the net.ipv6.conf.<dev>.addr_gen_mode sysctl.
Signed-off-by Guillaume Nault <[email protected]>
There are some helpers from lib.sh that could have been used, but the test is very clean and easy to follow, so:
Thanks!
Re: [PATCH net v2 2/2] selftests: Add IPv6 link-local address generation tests for GRE devices.
Quoted 11 lines · Ido Schimmel
Quoted 8 lines · Guillaume Nault
GRE devices have their special code for IPv6 link-local address generation that has been the source of several regressions in the past.
Add selftest to check that all gre, ip6gre, gretap and ip6gretap get an IPv6 link-link local address in accordance with the net.ipv6.conf.<dev>.addr_gen_mode sysctl.
Signed-off-by Guillaume Nault <[email protected]>There are some helpers from
lib.shthat could have been used,
Yes, I reused a personnal template that predates lib.sh. Given how simple is the setup of this selftest, I'm not sure if it's worth including lib.sh. But I might consider doing that in v2.
Quoted 7 lines
but the test is very clean and easy to follow, so:
Reviewed-by Ido Schimmel <[email protected]>Tested-by Ido Schimmel <[email protected]>Thanks!
Re: [PATCH net v2 2/2] selftests: Add IPv6 link-local address generation tests for GRE devices.
Quoted 9 lines · Guillaume Nault
Quoted 8 lines · Ido Schimmel
Quoted 7 lines · Guillaume Nault
GRE devices have their special code for IPv6 link-local address generation that has been the source of several regressions in the past.
Add selftest to check that all gre, ip6gre, gretap and ip6gretap get an IPv6 link-link local address in accordance with the net.ipv6.conf.<dev>.addr_gen_mode sysctl.
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Guillaume Nault <[email protected]>There are some helpers from
lib.shthat could have been used,Yes, I reused a personnal template that predates
lib.sh. Given how simple is the setup of this selftest, I'm not sure if it's worth includinglib.sh. But I might consider doing that in v2.
I've finally prefered to keep the script as-is. Reusing lib.sh wouldn't simplify much, but would require to use bash. And just changing the shebang to "#! /bin/bash" adds a 1.5 second penalty to the selftest execution time. That's acceptable of course, but I'm getting a bit tired of kselftests execution time, so I'd rather not contribute to increasing it uselessly.
Quoted 7 lines
Quoted 7 lines
but the test is very clean and easy to follow, so:
Reviewed-by Ido Schimmel <[email protected]>Tested-by Ido Schimmel <[email protected]>Thanks!