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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 22 Apr 2021 20:50:09 +0200
    From:        =?UTF-8?Q?J=C3=B6rn_Clausen?= <joernc%googlemail.com@localhost>
    Message-ID:  <CABFsXQesNjw1zhtfGbAH2OyXFydFngafmpFFCfWnx6Q9642T1g%mail.gmail.com@localhost>

  | $ 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