On 16 February 2017 at 10:42, Alice Wonder <al...@domblogger.net> wrote:
> On 02/16/2017 02:32 AM, James Hogarth wrote:
>>
>> On 16 February 2017 at 10:17, Alice Wonder <al...@domblogger.net> wrote:
>>>
>>> On 02/16/2017 02:03 AM, James Hogarth wrote:
>>>>
>>>>
>>>> On 16 February 2017 at 09:09, Alice Wonder <al...@domblogger.net> wrote:
>>>>>
>>>>>
>>>>> On 02/16/2017 12:54 AM, Tony Mountifield wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> In article <4cbb9dc4-f063-3434-b7a1-d4d0e6581...@domblogger.net>,
>>>>>> Alice Wonder <al...@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@centos.org
https://lists.centos.org/mailman/listinfo/centos

Reply via email to