Re: IPv6: in6_setscope: can't set scope for not loopback interface

Hello Robert!

Thanks for the reply. As you suggested, I tried tcpdump. BTW: This is all happening on the actual network interface, not the loopback interface.

I can see a constant stream of these packets:

10:31:46.504046 IP6 2a04:52c0:101:7b1::.5344 > ff15::efc0:988f.6771: UDP, length 138
10:31:48.502125 IP6 2a04:52c0:101:7b1::.60918 > ff15::efc0:988f.6771: UDP, length 138
10:31:48.502518 IP6 2a04:52c0:101:7b1::.42225 > ff15::efc0:988f.6771: UDP, length 138
10:31:48.502537 IP6 2a04:52c0:101:7b1::.33293 > ff15::efc0:988f.6771: UDP, length 138
10:31:48.502647 IP6 2a04:52c0:101:7b1::.51209 > ff15::efc0:988f.6771: UDP, length 138

2a04:52c0:101:7b1 is on the same network as my machine (technically, my ISP gave me the address 2a04:52c0:101:162::/64, but I don't use it and haven't configured the interface with it).

Every now and then I see this:

10:31:49.689606 IP6 ::1.52736 > ff15::efc0:988f.6771: UDP, length 139
10:31:49.690455 IP6 ::1.6771 > ff15::efc0:988f.6771: UDP, length 139
10:31:51.690739 IP6 ::1.52736 > ff15::efc0:988f.6771: UDP, length 139
10:31:51.691180 IP6 ::1.6771 > ff15::efc0:988f.6771: UDP, length 139

and this correlates perfectly with /var/log/messages:

[Thu Apr 22 10:31:49 CEST 2021 < 27.000723>] in6_setscope: can't set scope for not loopback interface vioif0 and loopback address ::1
[Thu Apr 22 10:31:49 CEST 2021 < 0.000000>] in6_setscope: can't set scope for not loopback interface vioif0 and loopback address ::1
[Thu Apr 22 10:31:51 CEST 2021 < 2.002278>] in6_setscope: can't set scope for not loopback interface vioif0 and loopback address ::1
[Thu Apr 22 10:31:51 CEST 2021 < 0.000000>] in6_setscope: can't set scope for not loopback interface vioif0 and loopback address ::1

So I see packets on my network interface (i.e. not the loopback interface) with a source of ::1. I am waiting for a reply from my ISP if I am seeing pink elephants or if there are actually such packets on the network.

Do you know if port 6771 is some well-known port in IPv6 for housekeeping? The information I found seem to lean more to malware, and 2a04:52c0:101:7b1 might not be acting in good faith...?

On Thu, Apr 22, 2021 at 8:29 AM Robert Elz <kre%munnari.oz.au@localhost> wrote:

Date: Wed, 21 Apr 2021 22:50:40 +0200
From: =?UTF-8?Q?J=C3=B6rn_Clausen?= <joernc%googlemail.com@localhost>
Message-ID: <CABFsXQeRXOjLwtm63REgTNS5OFiAxv44E-vA+R5zYzsoEo+dNA%mail.gmail.com@localhost>

| I am mostly ignorant to everything IPv6, so I have no clue what that
| message means, and I was not able to find any enlightenment online.

IPv6 link local (and multicast, and sometimes some other) addresses
have a "scope" in addition to the address itself. That's because there
is nothing in the address which indicates which interface it belongs
to (no sub-net identifier or anything like that).

The reference to ::1 in the messages is interesting, that's the v6
equivalent of 127.0.0.1 in V4 - the loopback address, and should only
be assigned to lo0 (but needs to be there).

| Is this something I can fix from inside the OS?

Almost certainly. There's probably something mis-configured.

What is the status of the loopback interface (lo0) ?

Mine looks like:

lo0: flags=0x8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33624
inet 127.0.0.1/8 flags 0x0
inet6 ::1/128 flags 0x20<NODAD>
inet6 fe80::1%lo0/64 flags 0x0 scopeid 0x3

| $ ifconfig vioif0
| vioif0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
| ec_capabilities=1<VLAN_MTU>
| ec_enabled=0
| address: 00:16:3e:b3:00:8a
| inet 5.2.76.44/24 broadcast 5.2.76.255 flags 0x0
| inet6 fe80::216:3eff:feb3:8a%vioif0/64 flags 0x0 scopeid 0x1

Nothing looks wrong there

fe80::216:3eff:feb3:8a

is your link local address on that interface, the "%vioif0" is the
scope (and the /64 is essentially the netmask of course).

While the changes at your ISP may have triggered something, and of
course it is possible they're doing something incorrect or unusual, it
is probably more likely that it is just different.

You might want to capture a short sequence of packets on that interface
to see what is happening, since the timestamps you included show the
messages appearing several times a minute, capturing packets for just
a minute or two should be enough to see if there's anything strange.

tcpdump -i vioif0 -s 1600 -w /tmp/packets.pcap ip6

should do it, simply interrupt it after a couple of minutes. Then you
can use tcpdump -r or wireshark to look at the packets, or put the file
somewhere it can be fetched.

kre