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 <[email protected]> wrote: > Date: Wed, 21 Apr 2021 22:50:40 +0200 > From: =?UTF-8?Q?J=C3=B6rn_Clausen?= <[email protected]> > Message-ID: < > cabfsxqerxojlwtm63regtns5ofiaxv44e-va+r5zyzsoeo+...@mail.gmail.com> > > | 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 > > -- Joern Clausen https://www.oe-files.de/photography/
