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.> >> >> It's all very frustrating but I suspect now the problem isn't the CentOS >> network configuration. >> > > Sounds likely ... depending on what there RA's say and how dhcpv6 is > being handled there (if at all) it could drastically affect things - > particularly if MAC changed on migration. > >> Five other servers all configured the same (started from same CentOS 7 image >> and network stuff left alone) work properly - so I don't know. >> > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >
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
On 02/16/2017 03:28 AM, James Hogarth wrote:> 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 > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >ipv6.ip6-privacy: -1 (unknown) ipv6.addr-gen-mode: stable-privacy