Re: IPv6: in6_setscope: can't set scope for not loopback interface
Actually, you can ignore the "-s1600" request, looks as if someone has finally made tcpdumps default snap length somewhat bigger... It won't hurt if you have done it using that option, but it also should no longer (I have no idea for how long back into the past) be needed. kre
Re: IPv6: in6_setscope: can't set scope for not loopback interface
Date:Thu, 22 Apr 2021 20:50:09 +0200 From:=?UTF-8?Q?J=C3=B6rn_Clausen?= Message-ID: | $ ifconfig -a That all looks OK, | I have configured the IPv4 part of vioif0 via /etc/ifconfig.vioif0: Now I'm going to suggest that you (at least temporarily) configure a v6 address on that interface. My suspicion is that something on your system is seeing those v6 incoming multicast packets, and is attempting to reply (with its own multicast packets). But you have no global address - the only non link-local v6 address it can find is ::1. If all of this goes away when you have a v6 address configured, then we'll be much closer to finding out what is going on. Just add inet6 2a04:52c0:101:162::1/64 at the end of /etc/ifconfig.vioif0 (the '1' could be any 16 bit hex value you like, there are more ways to config v6 addrs, but this will do for now). The 2a04:52c0:101:162 is what you said your ISP assigned you. | and define the default route in /etc/rc.conf. don't bother with that for ipv6 for now (no default v6 route). | According to my ISP, he doesn't see the bogus packets with ::1 source, so | indeed they seem to be a product of my machine. Assuming that's correct, which this test should verify (those packets should go away and be replaced by packets from 2a04:52c0:101:162::1 if my guess is correct) then we need to try and work out why the network stack is allowing that to happen. | the resulting PCAP file is at | | https://drive.google.com/file/d/1b_QlSW_oqYb2lMe4m_FO-DU7mAQdd86c/view?usp=sharing I'm unable to fetch that (or rather, I can connect to that page, but all it ever does is show a "rotating circle" kind of thing). Can you just send the pcap file (or perhaps a new version) to me (not the list) via e-mail? A second tcpdump pcap file after the v6 global addr is configured might help as well. And please, use -s 1600 on the tcpdump command that writes the file - I'm not certain that it is required when -w is used, but it certainly won't hurt (without that, only the packet headers tend to be captured, and sometimes not even all that, 1600 is bigger than the MTU (plus ethernet headers) so should get everything). kre
Re: IPv6: in6_setscope: can't set scope for not loopback interface
Hello Robert, Andy and everyone! I hope I address all the questions... As requested: $ ifconfig -a vioif0: flags=0x8843 mtu 1500 ec_capabilities=1 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 lo0: flags=0x8049 mtu 33624 inet 127.0.0.1/8 flags 0x0 inet6 ::1/128 flags 0x20 inet6 fe80::1%lo0/64 flags 0x0 scopeid 0x2 I have configured the IPv4 part of vioif0 via /etc/ifconfig.vioif0: up 5.2.76.44 netmask 255.255.255.0 and define the default route in /etc/rc.conf. That's all the configuration I do, everything else comes out of the box. If I boot the machine from the NetBSD 9.1 installation ISO and do "ifconfig vioif0 up", I immediately receive the messages on the console. According to my ISP, he doesn't see the bogus packets with ::1 source, so indeed they seem to be a product of my machine. I did $ tcpdump -i vioif0 -w /tmp/ip6.pcap ip6 for a minute or so, the resulting PCAP file is at https://drive.google.com/file/d/1b_QlSW_oqYb2lMe4m_FO-DU7mAQdd86c/view?usp=sharing On Thu, Apr 22, 2021 at 6:21 PM Robert Elz wrote: > Date:Thu, 22 Apr 2021 11:06:04 +0200 > From:=?UTF-8?Q?J=C3=B6rn_Clausen?= > Message-ID: < > cabfsxqcc0vagqfvqdpafyu-snrpgculwjsyvf5wsnttuhay...@mail.gmail.com> > > | BTW: This is all happening on the actual network interface, > | not the loopback interface. > > Yes, I knew that, but the NetBSD network stack uses the loopback > interface for local packet delivery, it has to be configured correctly > or (some) things won't work. > > | 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 > > Those are multicast packets. Multicast is one of the packet types for > which the interface scopes are important. > > What port 6771 is being used for I'm not sure, /etc/services says it is > "plysrv-https" (yes, including for UDP) but it might easily be something > else. Maybe someone else here can recognise it. Of you might check, > initially using netstat, and then perhaps fstat, whether your host has > anything listening on that port. > > | 2a04:52c0:101:7b1 is on the same network as my machine > > That would be a network prefix, the source addr is be 2a04:52c0:101:7b1:: > (those extra colons are important, and indicate a host part of all zeroes, > which is unusual, but I don't think actually incorrect). > > | (technically, my ISP gave me the address 2a04:52c0:101:162::/64, > > That's also a network prefix (a block of 2^64 addresses). A different > one that the prefix of the sender of those packets, though it is unclear > what that prefix (the one assigned to you) is intended for - most likely > for your internal network (if you have one, which for your usage you > probably don't) rather than for the link between the ISP and you, which > might be the 2a04:52c0:101:7b1 prefix. > > | but I don't use it and haven't configured the interface with it). > > That won't stop multicast packets arriving, the switch shouldn't be > sending them unless something has joined the multicast group, but without > knowing a lot more about how your ISP has configured the connections to > its kvm guests, it is hard to say that anything wrong is happening. > > | 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 > > Those are simply wrong. That ::1 source addr should never be attempting > to send any packets off its host - and if they're arriving over the vioif0 > interface, rather than being send, then some other host out there is > horribly broken (I'd tend to suspect your config first though). > > | 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 > > Yes, it would. Those packets are nonsense. > > | 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. > > If there are, the sender of them needs to be fixed, but I wouldn't be > surprised if something on your host is trying to send those. > > | Do you know if port 6771 is some well-known port in IPv6 for > housekeeping? > > No, it is not a port I recognise. But that means nothing. > > | The information I found seem to lean more to malware, and > 2a04:52c0:101:7b1 > | might not be acting in good faith...? > > I don't
Re: IPv6: in6_setscope: can't set scope for not loopback interface
Date:Thu, 22 Apr 2021 11:06:04 +0200 From:=?UTF-8?Q?J=C3=B6rn_Clausen?= Message-ID: | BTW: This is all happening on the actual network interface, | not the loopback interface. Yes, I knew that, but the NetBSD network stack uses the loopback interface for local packet delivery, it has to be configured correctly or (some) things won't work. | 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 Those are multicast packets. Multicast is one of the packet types for which the interface scopes are important. What port 6771 is being used for I'm not sure, /etc/services says it is "plysrv-https" (yes, including for UDP) but it might easily be something else. Maybe someone else here can recognise it. Of you might check, initially using netstat, and then perhaps fstat, whether your host has anything listening on that port. | 2a04:52c0:101:7b1 is on the same network as my machine That would be a network prefix, the source addr is be 2a04:52c0:101:7b1:: (those extra colons are important, and indicate a host part of all zeroes, which is unusual, but I don't think actually incorrect). | (technically, my ISP gave me the address 2a04:52c0:101:162::/64, That's also a network prefix (a block of 2^64 addresses). A different one that the prefix of the sender of those packets, though it is unclear what that prefix (the one assigned to you) is intended for - most likely for your internal network (if you have one, which for your usage you probably don't) rather than for the link between the ISP and you, which might be the 2a04:52c0:101:7b1 prefix. | but I don't use it and haven't configured the interface with it). That won't stop multicast packets arriving, the switch shouldn't be sending them unless something has joined the multicast group, but without knowing a lot more about how your ISP has configured the connections to its kvm guests, it is hard to say that anything wrong is happening. | 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 Those are simply wrong. That ::1 source addr should never be attempting to send any packets off its host - and if they're arriving over the vioif0 interface, rather than being send, then some other host out there is horribly broken (I'd tend to suspect your config first though). | 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 Yes, it would. Those packets are nonsense. | 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. If there are, the sender of them needs to be fixed, but I wouldn't be surprised if something on your host is trying to send those. | Do you know if port 6771 is some well-known port in IPv6 for housekeeping? No, it is not a port I recognise. But that means nothing. | The information I found seem to lean more to malware, and 2a04:52c0:101:7b1 | might not be acting in good faith...? I don't think I'd be assuming malware, when mistakes are far more likely. The two most likely possibilities are some kind of mis-config on your host, or some kind of mis-config on some other host running in a different KVM guest on the same server. kre
Re: IPv6: in6_setscope: can't set scope for not loopback interface
On Thu, Apr 22, 2021 at 2:10 AM Jörn Clausen wrote: > > 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. Yes but it's still useful to see ifconfig -a output as he asked for in case you have some strange setup locally. Andy
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.00>] 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.00>] 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 wrote: > Date:Wed, 21 Apr 2021 22:50:40 +0200 > From:=?UTF-8?Q?J=C3=B6rn_Clausen?= > 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 mtu 33624 > inet 127.0.0.1/8 flags 0x0 > inet6 ::1/128 flags 0x20 > inet6 fe80::1%lo0/64 flags 0x0 scopeid 0x3 > > > | $ ifconfig vioif0 > | vioif0: flags=0x8843 mtu 1500 > | ec_capabilities=1 > | 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/
Re: IPv6: in6_setscope: can't set scope for not loopback interface
Date:Wed, 21 Apr 2021 22:50:40 +0200 From:=?UTF-8?Q?J=C3=B6rn_Clausen?= Message-ID: | 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 mtu 33624 inet 127.0.0.1/8 flags 0x0 inet6 ::1/128 flags 0x20 inet6 fe80::1%lo0/64 flags 0x0 scopeid 0x3 | $ ifconfig vioif0 | vioif0: flags=0x8843 mtu 1500 | ec_capabilities=1 | 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
