On 16 February 2017 at 10:42, Alice Wonder <alice at domblogger.net> wrote: > On 02/16/2017 02:32 AM, James Hogarth wrote: >> >> On 16 February 2017 at 10:17, Alice Wonder <alice at domblogger.net> wrote: >>> >>> On 02/16/2017 02:03 AM, James Hogarth wrote: >>>> >>>> >>>> On 16 February 2017 at 09:09, Alice Wonder <alice at domblogger.net> wrote: >>>>> >>>>> >>>>> On 02/16/2017 12:54 AM, Tony Mountifield wrote: >>>>>> >>>>>> >>>>>> >>>>>> In article <4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e at domblogger.net>, >>>>>> Alice Wonder <alice at domblogger.net> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://forum.linode.com/viewtopic.php?f=19&t=14570&p=72785 >>>>>>> >>>>>>> I can not figure out what I need to do. >>>>>>> >>>>>>> Apparently according to linode support, the VM is trying to grab an >>>>>>> IPv6 >>>>>>> address with some privacy stuff enabled by default causing it to not >>>>>>> grab the IPv6 address that is assigned to me. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Does the accepted answer at the following link give you any useful >>>>>> hints? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> http://superuser.com/questions/243669/how-to-avoid-exposing-my-mac-address-when-using-ipv6 >>>>>> >>>>>> Cheers >>>>>> Tony >>>>>> >>>>> >>>>> Not really - I tried >>>>> >>>>> net.ipv6.conf.all.use_tempaddr = 0 >>>>> >>>>> and it still fails to grab the proper IPv6 >>>>> >>>>> -=- >>>>> >>>>> Just in case, I did ask Linode support to verify that my hardware >>>>> address >>>>> is >>>>> what it is suppose to be. Still waiting to hear on that. >>>>> >>>>> _______________________________________________ >>>> >>>> >>>> >>>> >>>> it still is key=value ... it uses the ifcfg- files (via the rh >>>> plugin) and they are all key=value >>>> >>>> It would be helpful if you could paste the journal output (journalctl >>>> -u NetworkManager) from the time period of attempting to get an >>>> address ... >>>> >>>> also the nmcli conn sh <connection_name> information for the interface >>>> along with your ifcfg- files >>> >>> >>> >>> ifcfg-lo is the only one that exists on any of the servers - including >>> the >>> VMs that grab the correct IPv6 address. >>> >>> from /sbin/ifconfig -a : >>> >> >> For a start stop using ifconfig ... it's broken at this point on >> linux, especially on multi ip and ipv6 scenarios >> >> Use `ip -6 addr sh` for ipv6 specfic stuff, or just ip addr sh to see >> all IP address stuff regardless of family >> >>> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 >>> inet 178.79.185.217 netmask 255.255.255.0 broadcast >>> 178.79.185.255 >>> inet6 fe80::a8ad:d312:4ef4:7272 prefixlen 64 scopeid 0x20<link> >>> inet6 2a01:7e00::825f:e564:ad53:72fc prefixlen 64 scopeid >>> 0x0<global> >>> ether f2:3c:91:18:8a:7e txqueuelen 1000 (Ethernet) >>> RX packets 9903 bytes 1088621 (1.0 MiB) >>> RX errors 0 dropped 0 overruns 0 frame 0 >>> TX packets 7786 bytes 1087223 (1.0 MiB) >>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >>> >>> That hardware address - the 18:8a:7e corresponds with what the IPv6 >>> address >>> is suppose to be. But that's not the address it is grabbing, despite the >>> fact that net.ipv6.conf.all.use_tempaddr = 0 is set. >>> >>> I'm seriously wondering if the real issue is a mis-configured dhcp server >>> in >>> their London facility because nothing makes sense. >>> >>> journalctl -u NetworkManager >>> >>> reports no journal entries found. >>> >> >> So are you not using NetworkManager then? there should be some logs ... >> >> >>> I think the problem must be on their end. >>> >>> It all was working fine until they migrated the VM because of a hardware >>> issue, and I suspect now all the hardware address privacy stuff being the >>> issue is barking up the wrong tree because all the reading I have done >>> seems >>> to indicate that with >>> >>> net.ipv6.conf.all.use_tempaddr = 0 >>> >>> that a fake temporary hardware address would not be sent to their dhcp >>> server when obtaining the address, but the real one, that should be >>> fetching >>> my assigned address. >> >> >> Only if the kernel is doing SLAAC ... if other things (eg NM) are >> handling it directly they may act differently ... but then from the >> lack of logs is NM actually handling this? >> >> Does systemctl status NetworkManager show it running and does nmcli >> show anything? >> > > systemctl status NetworkManager > ● NetworkManager.service - Network Manager > Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; > vendor preset: enabled) > Active: active (running) since Thu 2017-02-16 08:19:34 UTC; 2h 19min ago > > * more stuff * > > nmcli > eth0: connected to Wired connection 1 > "Red Hat Virtio network device" > ethernet (virtio_net), F2:3C:91:18:8A:7E, hw, mtu 1500 > ip4 default, ip6 default > inet4 178.79.185.217/24 > route4 178.79.187.246/32 > inet6 2a01:7e00::825f:e564:ad53:72fc/64 > inet6 fe80::a8ad:d312:4ef4:7272/64 > route6 2a01:7e00::/64 > > * more stuff for other interfaces * > > -=- > > The output of > > sysctl -a | grep net.ipv6 : > > https://librelamp.com/sysctl.txt > > It looks from that like it should not be hiding the real MAC address. > do nmcli conn show "Wired connection 1" the entries of interest are: ipv6.ip6-privacy ipv6.addr-gen-mode man nm-settings to get what they mean