Message-ID: <be4cd6bf2103caa42f475739a3dc6a841e1c6542.camel@alliedtelesis.co.nz>
Date:   Thu, 6 Apr 2023 22:59:33 +0000
From:   Thomas Winter <Thomas.Winter@...iedtelesis.co.nz>
To:     "ashumnik9@...il.com" <ashumnik9@...il.com>,
        "kuba@...nel.org" <kuba@...nel.org>
CC:     "edumazet@...gle.com" <edumazet@...gle.com>,
        "dsahern@...nel.org" <dsahern@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "a@...table.cc" <a@...table.cc>
Subject: Re: [BUG] gre interface incorrectly generates link-local addresses

Hello Aleksey,

Sorry, I was on leave during March so only getting to this now. I will
have a proper look at this when I get back to work on Tuesday and try
to reproduce your issue.

My issue was on our routers using kernel 5.15.89 and we don't
use /etc/network/interfaces for configuration. The tunnel was created
with netlink messages like with the "ip link" command and an IPv6 link
local address is generated by
setting /proc/sys/net/ipv6/conf/tunnel0/addr_gen_mode but this broke
after commit e5dd729460ca. I did not see any hanging addresses like you
described.

Regards,
Thomas

On Thu, 2023-04-06 at 18:04 +0300, Aleksey Shumnik wrote:
> Dear maintainers,
> 
> I remind you that the problem is still relevant.
> The problem is not only in generating the number of link-local
> addresses in an amount equal to the number of addresses on all
> interfaces defined in /etc/network/interfaces before the gre
> interface.
> Due to the new method of link-local address generation, the same
> link-local address may be formed on several gre interfaces, which may
> lead to errors in the operation of some network services
> 
> Would you please answer the following questions
> > Which linux distribution did you use when you found an error with
> > the
> > lack of link-local address generation on the gre interface?
> > After fixing the error, only one link-local address is generated?
> Is this a bug or an expected behavior?
> 
> On Sat, Mar 25, 2023 at 1:34 AM Jakub Kicinski <kuba@...nel.org>
> wrote:
> > Adding Thomas as well.
> > 
> > On Fri, 24 Mar 2023 19:35:06 +0300 Aleksey Shumnik wrote:
> > > Dear Maintainers,
> > > 
> > > I found that GRE arbitrarily hangs IP addresses from other
> > > interfaces
> > > described in /etc/network/interfaces above itself (from bottom to
> > > top). Moreover, this error occurs on both ip4gre and ip6gre.
> > > 
> > > Example of mgre interface:
> > > 
> > > 13: mgre1@...E: <MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc
> > > noqueue
> > > state UNKNOWN group default qlen 1000
> > >     link/gre 0.0.0.0 brd 0.0.0.0
> > >     inet 10.10.10.100/8 brd 10.255.255.255 scope global mgre1
> > >        valid_lft forever preferred_lft forever
> > >     inet6 fe80::a0a:a64/64 scope link
> > >        valid_lft forever preferred_lft forever
> > >     inet6 fe80::7f00:1/64 scope host
> > >        valid_lft forever preferred_lft forever
> > >     inet6 fe80::a0:6842/64 scope host
> > >        valid_lft forever preferred_lft forever
> > >     inet6 fe80::c0a8:1264/64 scope host
> > >        valid_lft forever preferred_lft forever
> > > 
> > > It seems that after the corrections in the following commits
> > > https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f
> > > https://github.com/torvalds/linux/commit/30e2291f61f93f7132c060190f8360df52644ec1
> > > https://github.com/torvalds/linux/commit/23ca0c2c93406bdb1150659e720bda1cec1fad04
> > > 
> > > in function add_v4_addrs() instead of stopping after this check:
> > > 
> > > if (addr.s6_addr32[3]) {
> > >                 add_addr(idev, &addr, plen, scope,
> > > IFAPROT_UNSPEC);
> > >                 addrconf_prefix_route(&addr, plen, 0, idev->dev,
> > > 0, pflags,
> > >                                                                 G
> > > FP_KERNEL);
> > >                  return;
> > > }
> > > 
> > > it goes further and in this cycle hangs addresses from all
> > > interfaces on the gre
> > > 
> > > for_each_netdev(net, dev) {
> > >       struct in_device *in_dev = __in_dev_get_rtnl(dev);
> > >       if (in_dev && (dev->flags & IFF_UP)) {
> > >       struct in_ifaddr *ifa;
> > >       int flag = scope;
> > >       in_dev_for_each_ifa_rtnl(ifa, in_dev) {
> > >             addr.s6_addr32[3] = ifa->ifa_local;
> > >             if (ifa->ifa_scope == RT_SCOPE_LINK)
> > >                      continue;
> > >             if (ifa->ifa_scope >= RT_SCOPE_HOST) {
> > >                      if (idev->dev->flags&IFF_POINTOPOINT)
> > >                               continue;
> > >                      flag |= IFA_HOST;
> > >             }
> > >             add_addr(idev, &addr, plen, flag,
> > >                                     IFAPROT_UNSPEC);
> > >             addrconf_prefix_route(&addr, plen, 0, idev->dev,
> > >                                      0, pflags, GFP_KERNEL);
> > >             }
> > > }
> > > 
> > > Moreover, before switching to Debian 12 kernel version 6.1.15, I
> > > used
> > > Debian 11 on 5.10.140, and there was no error described in the
> > > commit
> > > https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f.
> > > One link-local address was always generated on the gre interface,
> > > regardless of whether the destination or the local address of the
> > > tunnel was specified.
> > > 
> > > Which linux distribution did you use when you found an error with
> > > the
> > > lack of link-local address generation on the gre interface?
> > > After fixing the error, only one link-local address is generated?
> > > I think this is a bug and most likely the problem is in
> > > generating
> > > dev->dev_addr, since link-local is formed from it.
> > > 
> > > I suggest solving this problem or roll back the code changes made
> > > in
> > > the comments above.

Powered by blists - more mailing lists