All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aleksey Shumnik <ashumnik9@gmail.com>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, yoshfuji@linux-ipv6.org, dsahern@kernel.org,
	pabeni@redhat.com, edumazet@google.com,
	Jakub Kicinski <kuba@kernel.org>,
	a@unstable.cc, linux-kernel@vger.kernel.org
Subject: [BUG] gre interface incorrectly generates link-local addresses
Date: Fri, 24 Mar 2023 19:35:06 +0300	[thread overview]
Message-ID: <CAJGXZLhL-LLjiA-ge8O5A5NDoZ5JABqZHqix0y-8ThcJjBSe=A@mail.gmail.com> (raw)

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@NONE: <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,
                                                                GFP_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.

             reply	other threads:[~2023-03-24 16:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-24 16:35 Aleksey Shumnik [this message]
2023-03-24 22:34 ` [BUG] gre interface incorrectly generates link-local addresses Jakub Kicinski
2023-04-06 15:04   ` Aleksey Shumnik
2023-04-06 22:59     ` Thomas Winter
2023-04-13  0:33       ` Thomas Winter
2024-02-02 13:01 Антарио Просперо
2024-02-07 22:05 ` Thomas Winter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJGXZLhL-LLjiA-ge8O5A5NDoZ5JABqZHqix0y-8ThcJjBSe=A@mail.gmail.com' \
    --to=ashumnik9@gmail.com \
    --cc=a@unstable.cc \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.