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.
Nothing I have tried seems to work, and it seems that Linode support are far more familiar with Ubuntu than CentOS.
I know CentOS follows Red Hat so I'm not suggesting this is CentOS's fault, but stuff like this really is why I am a much bigger fan of KISS with simple key=value configuration files that don't seem to exist anymore with Linux networking in the Red Hat world.
Making things more complex to benefit "Cloud" servers it the worst thing Red Hat ever did.
Sorry for the tone, I'm quite frustrated and as an epileptic who doesn't drive, driving down to the SF Bay Area for RHCE classes that won't even be applicable in a few years when they change stuff again isn't really an option.
Been using Red Hat since MKLinux DR3 (based on Red Hat 5.1) and been through the training courses before and everything changes.
Anyone know what might be going on? And how to get dhclient to grab the "right" IPv6 address, the same one this VM grabbed no problem for well over a year?
In article 4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@domblogger.net, Alice Wonder alice@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-w...
Cheers Tony
On 02/16/2017 12:54 AM, Tony Mountifield wrote:
In article 4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@domblogger.net, Alice Wonder alice@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-w...
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.
On 16 February 2017 at 09:09, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 12:54 AM, Tony Mountifield wrote:
In article 4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@domblogger.net, Alice Wonder alice@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-w...
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
On 02/16/2017 02:03 AM, James Hogarth wrote:
On 16 February 2017 at 09:09, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 12:54 AM, Tony Mountifield wrote:
In article 4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@domblogger.net, Alice Wonder alice@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-w...
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 :
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.
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.
It's all very frustrating but I suspect now the problem isn't the CentOS network configuration.
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.
On 16 February 2017 at 10:17, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 02:03 AM, James Hogarth wrote:
On 16 February 2017 at 09:09, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 12:54 AM, Tony Mountifield wrote:
In article 4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@domblogger.net, Alice Wonder alice@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-w...
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?
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.
On 02/16/2017 02:32 AM, James Hogarth wrote:
On 16 February 2017 at 10:17, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 02:03 AM, James Hogarth wrote:
On 16 February 2017 at 09:09, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 12:54 AM, Tony Mountifield wrote:
In article 4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@domblogger.net, Alice Wonder alice@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-w...
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@centos.org https://lists.centos.org/mailman/listinfo/centos
On 16 February 2017 at 10:42, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 02:32 AM, James Hogarth wrote:
On 16 February 2017 at 10:17, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 02:03 AM, James Hogarth wrote:
On 16 February 2017 at 09:09, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 12:54 AM, Tony Mountifield wrote:
In article 4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@domblogger.net, Alice Wonder alice@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-w...
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@domblogger.net wrote:
On 02/16/2017 02:32 AM, James Hogarth wrote:
On 16 February 2017 at 10:17, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 02:03 AM, James Hogarth wrote:
On 16 February 2017 at 09:09, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 12:54 AM, Tony Mountifield wrote: > > > > In article 4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@domblogger.net, > Alice Wonder alice@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-w... > > 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@centos.org https://lists.centos.org/mailman/listinfo/centos
ipv6.ip6-privacy: -1 (unknown) ipv6.addr-gen-mode: stable-privacy
On 16 February 2017 at 11:35, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 03:28 AM, James Hogarth wrote:
On 16 February 2017 at 10:42, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 02:32 AM, James Hogarth wrote:
On 16 February 2017 at 10:17, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 02:03 AM, James Hogarth wrote:
On 16 February 2017 at 09:09, Alice Wonder alice@domblogger.net wrote: > > > > On 02/16/2017 12:54 AM, Tony Mountifield wrote: >> >> >> >> >> In article 4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@domblogger.net, >> Alice Wonder alice@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-w... >> >> 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@centos.org https://lists.centos.org/mailman/listinfo/centos
ipv6.ip6-privacy: -1 (unknown) ipv6.addr-gen-mode: stable-privacy
Okay so from the man page:
The permitted values are: "eui64", or "stable-privacy". If the property is set to "eui64", the addresses will be generated using the interface tokens derived from hardware address. This makes the host part of the address to stay constant, making it possible to track host's presence when it changes networks. The address changes when the interface hardware is replaced. The value of "stable-privacy" enables use of cryptographically secure hash of a secret host-specific key along with the connection identification and the network address as specified by RFC7217. This makes it impossible to use the address track host's presence, and makes the address stable when the network interface hardware is replaced.
I'm not certain (would have to go get changelogs) but I suspect this was a change at 7.3 with the rebase of NetworkManager
From what you say you want it sounds like you want eui64 - the one
based entire on the current MAC - whereas the present version is using stable-privacy to avoid tracking.
Note that this is distinct and different to ip6-privacy which is concerned about the automatic generation of temporary addresses to use for outbound communication.
On 16 February 2017 at 11:46, James Hogarth james.hogarth@gmail.com wrote:
On 16 February 2017 at 11:35, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 03:28 AM, James Hogarth wrote:
On 16 February 2017 at 10:42, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 02:32 AM, James Hogarth wrote:
On 16 February 2017 at 10:17, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 02:03 AM, James Hogarth wrote: > > > > On 16 February 2017 at 09:09, Alice Wonder alice@domblogger.net > wrote: >> >> >> >> On 02/16/2017 12:54 AM, Tony Mountifield wrote: >>> >>> >>> >>> >>> In article 4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@domblogger.net, >>> Alice Wonder alice@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-w... >>> >>> 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@centos.org https://lists.centos.org/mailman/listinfo/centos
ipv6.ip6-privacy: -1 (unknown) ipv6.addr-gen-mode: stable-privacy
Okay so from the man page:
The permitted values are: "eui64", or "stable-privacy". If the property is set to "eui64", the addresses will be generated using the interface tokens derived from hardware address. This makes the host part of the address to stay constant, making it possible to track host's presence when it changes networks. The address changes when the interface hardware is replaced. The value of "stable-privacy" enables use of cryptographically secure hash of a secret host-specific key along with the connection identification and the network address as specified by RFC7217. This makes it impossible to use the address track host's presence, and makes the address stable when the network interface hardware is replaced.
I'm not certain (would have to go get changelogs) but I suspect this was a change at 7.3 with the rebase of NetworkManager
From what you say you want it sounds like you want eui64 - the one based entire on the current MAC - whereas the present version is using stable-privacy to avoid tracking.
Note that this is distinct and different to ip6-privacy which is concerned about the automatic generation of temporary addresses to use for outbound communication.
Okay a little more research as I'm curious when it changed from EUI64 by default ...
https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-th...
NM changed upstream to stable-privacy at 1.2 (the privacy extensions for the external connections were added at 1.0.4)
RHEL 7.2 enabled privacy extensions by default:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
But at that milestone we had NM 1.0.6
At the RHEL 7.3 release NM was rebased to 1.4.0
It was briefly referenced with this change in the 7.3 release notes but honestly it's pretty opaque ...
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
"NetworkManager now supports new device types, improved stacking of virtual devices, LLDP, stable privacy IPv6 addresses (RFC 7217), detects duplicate IPv4 addresses, and controls a host name through systemd-hostnamed. Additionally, the user can set a DHCP timeout property and DNS priorities."
Of course unless you knew what RFC 7217 was you'd have no idea this was the effect and there's no note that stable-privacy is the new default behaviour ARGH
Disappointingly it's not listed in the "Networking" part of the release notes ....
I think I'll raise the priority on my blog for the article I'm intending on the NM rebase ... there are nice things in the rebase like the arbitrary layering of teams, vlans and bridges but then there's unexpected stuff like this as well which should be made more visible.
So ... Alice if you want to configure the system with the older EUI64 behaviour then in your ifcfg file for that interface you need IPV6_ADDR_GEN_MODE=eui64 and then restart NetworkManager (or `nmcli conn reload` rather than a full service restart or `nmcli conn mod "Wired Connection 1" ipv6.addr-gen-mode eui64` to do it at the CLI without editing files and needing a connection reload).
On 16 February 2017 at 12:02, James Hogarth james.hogarth@gmail.com wrote:
On 16 February 2017 at 11:46, James Hogarth james.hogarth@gmail.com wrote:
On 16 February 2017 at 11:35, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 03:28 AM, James Hogarth wrote:
On 16 February 2017 at 10:42, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 02:32 AM, James Hogarth wrote:
On 16 February 2017 at 10:17, Alice Wonder alice@domblogger.net wrote: > > > On 02/16/2017 02:03 AM, James Hogarth wrote: >> >> >> >> On 16 February 2017 at 09:09, Alice Wonder alice@domblogger.net >> wrote: >>> >>> >>> >>> On 02/16/2017 12:54 AM, Tony Mountifield wrote: >>>> >>>> >>>> >>>> >>>> In article 4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@domblogger.net, >>>> Alice Wonder alice@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-w... >>>> >>>> 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@centos.org https://lists.centos.org/mailman/listinfo/centos
ipv6.ip6-privacy: -1 (unknown) ipv6.addr-gen-mode: stable-privacy
Okay so from the man page:
The permitted values are: "eui64", or "stable-privacy". If the property is set to "eui64", the addresses will be generated using the interface tokens derived from hardware address. This makes the host part of the address to stay constant, making it possible to track host's presence when it changes networks. The address changes when the interface hardware is replaced. The value of "stable-privacy" enables use of cryptographically secure hash of a secret host-specific key along with the connection identification and the network address as specified by RFC7217. This makes it impossible to use the address track host's presence, and makes the address stable when the network interface hardware is replaced.
I'm not certain (would have to go get changelogs) but I suspect this was a change at 7.3 with the rebase of NetworkManager
From what you say you want it sounds like you want eui64 - the one based entire on the current MAC - whereas the present version is using stable-privacy to avoid tracking.
Note that this is distinct and different to ip6-privacy which is concerned about the automatic generation of temporary addresses to use for outbound communication.
Okay a little more research as I'm curious when it changed from EUI64 by default ...
https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-th...
NM changed upstream to stable-privacy at 1.2 (the privacy extensions for the external connections were added at 1.0.4)
RHEL 7.2 enabled privacy extensions by default:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
But at that milestone we had NM 1.0.6
At the RHEL 7.3 release NM was rebased to 1.4.0
It was briefly referenced with this change in the 7.3 release notes but honestly it's pretty opaque ...
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
"NetworkManager now supports new device types, improved stacking of virtual devices, LLDP, stable privacy IPv6 addresses (RFC 7217), detects duplicate IPv4 addresses, and controls a host name through systemd-hostnamed. Additionally, the user can set a DHCP timeout property and DNS priorities."
Of course unless you knew what RFC 7217 was you'd have no idea this was the effect and there's no note that stable-privacy is the new default behaviour ARGH
Disappointingly it's not listed in the "Networking" part of the release notes ....
I think I'll raise the priority on my blog for the article I'm intending on the NM rebase ... there are nice things in the rebase like the arbitrary layering of teams, vlans and bridges but then there's unexpected stuff like this as well which should be made more visible.
So ... Alice if you want to configure the system with the older EUI64 behaviour then in your ifcfg file for that interface you need IPV6_ADDR_GEN_MODE=eui64 and then restart NetworkManager (or `nmcli conn reload` rather than a full service restart or `nmcli conn mod "Wired Connection 1" ipv6.addr-gen-mode eui64` to do it at the CLI without editing files and needing a connection reload).
Oh and last message about this ...
This was the email to fedora-devel at the time of the NM 1.2 introduction:
https://lists.fedoraproject.org/pipermail/devel/2015-November/216754.html
Systems that existed prior to the package didn't change their configuration, it was only newly built systems that picked up the new default - which might explain what you saw depending on how they handled the migration.
There's a good reason that stable-privacy was moved to for automatic addressing, but for your setup you may want to set the older eui64 to keep things consistent.
On 02/16/2017 04:20 AM, James Hogarth wrote:
On 16 February 2017 at 12:02, James Hogarth james.hogarth@gmail.com wrote:
On 16 February 2017 at 11:46, James Hogarth james.hogarth@gmail.com wrote:
On 16 February 2017 at 11:35, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 03:28 AM, James Hogarth wrote:
On 16 February 2017 at 10:42, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 02:32 AM, James Hogarth wrote: > > > On 16 February 2017 at 10:17, Alice Wonder alice@domblogger.net wrote: >> >> >> On 02/16/2017 02:03 AM, James Hogarth wrote: >>> >>> >>> >>> On 16 February 2017 at 09:09, Alice Wonder alice@domblogger.net >>> wrote: >>>> >>>> >>>> >>>> On 02/16/2017 12:54 AM, Tony Mountifield wrote: >>>>> >>>>> >>>>> >>>>> >>>>> In article 4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@domblogger.net, >>>>> Alice Wonder alice@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-w... >>>>> >>>>> 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@centos.org https://lists.centos.org/mailman/listinfo/centos
ipv6.ip6-privacy: -1 (unknown) ipv6.addr-gen-mode: stable-privacy
Okay so from the man page:
The permitted values are: "eui64", or "stable-privacy". If the property is set to "eui64", the addresses will be generated using the interface tokens derived from hardware address. This makes the host part of the address to stay constant, making it possible to track host's presence when it changes networks. The address changes when the interface hardware is replaced. The value of "stable-privacy" enables use of cryptographically secure hash of a secret host-specific key along with the connection identification and the network address as specified by RFC7217. This makes it impossible to use the address track host's presence, and makes the address stable when the network interface hardware is replaced.
I'm not certain (would have to go get changelogs) but I suspect this was a change at 7.3 with the rebase of NetworkManager
From what you say you want it sounds like you want eui64 - the one based entire on the current MAC - whereas the present version is using stable-privacy to avoid tracking.
Note that this is distinct and different to ip6-privacy which is concerned about the automatic generation of temporary addresses to use for outbound communication.
Okay a little more research as I'm curious when it changed from EUI64 by default ...
https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-th...
NM changed upstream to stable-privacy at 1.2 (the privacy extensions for the external connections were added at 1.0.4)
RHEL 7.2 enabled privacy extensions by default:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
But at that milestone we had NM 1.0.6
At the RHEL 7.3 release NM was rebased to 1.4.0
It was briefly referenced with this change in the 7.3 release notes but honestly it's pretty opaque ...
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
"NetworkManager now supports new device types, improved stacking of virtual devices, LLDP, stable privacy IPv6 addresses (RFC 7217), detects duplicate IPv4 addresses, and controls a host name through systemd-hostnamed. Additionally, the user can set a DHCP timeout property and DNS priorities."
Of course unless you knew what RFC 7217 was you'd have no idea this was the effect and there's no note that stable-privacy is the new default behaviour ARGH
Disappointingly it's not listed in the "Networking" part of the release notes ....
I think I'll raise the priority on my blog for the article I'm intending on the NM rebase ... there are nice things in the rebase like the arbitrary layering of teams, vlans and bridges but then there's unexpected stuff like this as well which should be made more visible.
So ... Alice if you want to configure the system with the older EUI64 behaviour then in your ifcfg file for that interface you need IPV6_ADDR_GEN_MODE=eui64 and then restart NetworkManager (or `nmcli conn reload` rather than a full service restart or `nmcli conn mod "Wired Connection 1" ipv6.addr-gen-mode eui64` to do it at the CLI without editing files and needing a connection reload).
Oh and last message about this ...
This was the email to fedora-devel at the time of the NM 1.2 introduction:
https://lists.fedoraproject.org/pipermail/devel/2015-November/216754.html
Systems that existed prior to the package didn't change their configuration, it was only newly built systems that picked up the new default - which might explain what you saw depending on how they handled the migration.
There's a good reason that stable-privacy was moved to for automatic addressing, but for your setup you may want to set the older eui64 to keep things consistent. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I suspect this is it. However -
cat /etc/sysconfig/network-scripts/ifcfg-eth0 IPV6_ADDR_GEN_MODE=eui64
yet it still lists stable-privacy
But I think that is it, so I'll figure it out.
Thank you so much.
On 02/16/2017 04:34 AM, Alice Wonder wrote:
On 02/16/2017 04:20 AM, James Hogarth wrote:
On 16 February 2017 at 12:02, James Hogarth james.hogarth@gmail.com wrote:
On 16 February 2017 at 11:46, James Hogarth james.hogarth@gmail.com wrote:
On 16 February 2017 at 11:35, Alice Wonder alice@domblogger.net wrote:
On 02/16/2017 03:28 AM, James Hogarth wrote:
On 16 February 2017 at 10:42, Alice Wonder alice@domblogger.net wrote: > > On 02/16/2017 02:32 AM, James Hogarth wrote: >> >> >> On 16 February 2017 at 10:17, Alice Wonder >> alice@domblogger.net wrote: >>> >>> >>> On 02/16/2017 02:03 AM, James Hogarth wrote: >>>> >>>> >>>> >>>> On 16 February 2017 at 09:09, Alice Wonder alice@domblogger.net >>>> wrote: >>>>> >>>>> >>>>> >>>>> On 02/16/2017 12:54 AM, Tony Mountifield wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> In article >>>>>> 4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e@domblogger.net, >>>>>> Alice Wonder alice@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-w... >>>>>> >>>>>> >>>>>> 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@centos.org https://lists.centos.org/mailman/listinfo/centos
ipv6.ip6-privacy: -1 (unknown) ipv6.addr-gen-mode: stable-privacy
Okay so from the man page:
The permitted values are: "eui64", or "stable-privacy". If the property is set to "eui64", the addresses will be generated using the interface tokens derived from hardware address. This makes the host part of the address to stay constant, making it possible to track host's presence when it changes networks. The address changes when the interface hardware is replaced. The value of "stable-privacy" enables use of cryptographically secure hash of a secret host-specific key along with the connection identification and the network address as specified by RFC7217. This makes it impossible to use the address track host's presence, and makes the address stable when the network interface hardware is replaced.
I'm not certain (would have to go get changelogs) but I suspect this was a change at 7.3 with the rebase of NetworkManager
From what you say you want it sounds like you want eui64 - the one based entire on the current MAC - whereas the present version is using stable-privacy to avoid tracking.
Note that this is distinct and different to ip6-privacy which is concerned about the automatic generation of temporary addresses to use for outbound communication.
Okay a little more research as I'm curious when it changed from EUI64 by default ...
https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-th...
NM changed upstream to stable-privacy at 1.2 (the privacy extensions for the external connections were added at 1.0.4)
RHEL 7.2 enabled privacy extensions by default:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
But at that milestone we had NM 1.0.6
At the RHEL 7.3 release NM was rebased to 1.4.0
It was briefly referenced with this change in the 7.3 release notes but honestly it's pretty opaque ...
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
"NetworkManager now supports new device types, improved stacking of virtual devices, LLDP, stable privacy IPv6 addresses (RFC 7217), detects duplicate IPv4 addresses, and controls a host name through systemd-hostnamed. Additionally, the user can set a DHCP timeout property and DNS priorities."
Of course unless you knew what RFC 7217 was you'd have no idea this was the effect and there's no note that stable-privacy is the new default behaviour ARGH
Disappointingly it's not listed in the "Networking" part of the release notes ....
I think I'll raise the priority on my blog for the article I'm intending on the NM rebase ... there are nice things in the rebase like the arbitrary layering of teams, vlans and bridges but then there's unexpected stuff like this as well which should be made more visible.
So ... Alice if you want to configure the system with the older EUI64 behaviour then in your ifcfg file for that interface you need IPV6_ADDR_GEN_MODE=eui64 and then restart NetworkManager (or `nmcli conn reload` rather than a full service restart or `nmcli conn mod "Wired Connection 1" ipv6.addr-gen-mode eui64` to do it at the CLI without editing files and needing a connection reload).
Oh and last message about this ...
This was the email to fedora-devel at the time of the NM 1.2 introduction:
https://lists.fedoraproject.org/pipermail/devel/2015-November/216754.html
Systems that existed prior to the package didn't change their configuration, it was only newly built systems that picked up the new default - which might explain what you saw depending on how they handled the migration.
There's a good reason that stable-privacy was moved to for automatic addressing, but for your setup you may want to set the older eui64 to keep things consistent. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I suspect this is it. However -
cat /etc/sysconfig/network-scripts/ifcfg-eth0 IPV6_ADDR_GEN_MODE=eui64
yet it still lists stable-privacy
But I think that is it, so I'll figure it out.
Thank you so much.
nmcli c modify "Wired connection 1" ipv6.addr-gen-mode eui64
That solved it.
Again, thank you so much.
Now I need to set that on all my other linodes, which I suspect are only working on IPv6 because they haven't been restarted in a long time.
Having used Linode and CentOS for years I have never had a problem quite like this. Sure sounds like the IPv6 is misconfigured in the DHCP server or is in use somewhere. Some things I would try are:
1. Set "Auto configure networking" in your config profile and reboot. 2. Try to assign the adddress static. 3. Ask Linode to assign you a new IPv6 4. Wait for Linode to fix the problem.
Mike
On Thu, 2017-02-16 at 00:37 -0800, Alice Wonder 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.
I'm no IPv6 expert (as in I know nothing), but look at the options that dhclient is using when it's running - there are various v6 specific options that would affect what's happening. 'man dhclient' is useful here.
I know CentOS follows Red Hat so I'm not suggesting this is CentOS's fault, but stuff like this really is why I am a much bigger fan of KISS with simple key=value configuration files that don't seem to exist anymore with Linux networking in the Red Hat world.
Yes they do. Everything concerned with networking is held in flat files - they may be XML like files or some other structured approach, but they are there. What you are probably confusing it with is the fact that most of the config files are written by GUI applications or maintained by CLI commands rather than editing them by hand. That's all down to NetworkManager - love it or hate it, but the clue to what it does is in the name, it manages your network. If you don't want something to manage your network, don't use it.
Anyone know what might be going on? And how to get dhclient to grab the "right" IPv6 address, the same one this VM grabbed no problem for well over a year?
As I said, you need to look at dhclient configuration and command line options. If you have NetworkManager running then it will be controlling what dhclient does so manual editing the files will not work. Use nmcli to see what's happening and modify the configuration.
P.
--On Thursday, February 16, 2017 10:12 AM +0000 Pete Biggs pete@biggs.org.uk wrote:
As I said, you need to look at dhclient configuration and command line options. If you have NetworkManager running then it will be controlling what dhclient does so manual editing the files will not work. Use nmcli to see what's happening and modify the configuration.
It's not so much that editing files won't work, but that in many cases editing the files you're used to won't work. They're now generated from new flat files, and you have to dig around to figure out where the new configuration is hidden. It's a learning curve we all hate to climb, of course. Fortunately we have the source code for when the documentation is inadequate!
We see the same thing with the new firewalld. iptables didn't go away. It's just hidden behind firewalld configuration, which automatically writes iptables rules. I liken it to going from assembly language to a higher level language to describe my programming problems. And the new systems usually provide back doors that let you drop down to the more detailed implementation layer if absolutely needed.
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
-
Alice Wonder -
James Hogarth -
Kenneth Porter -
Mike McCarthy, W1NR -
Pete Biggs -
tony＠softins.co.uk