[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABWXKLxQYEMu9sDu+5RF+xfqGERUH19nq7hxukcohgxr43uRuQ@mail.gmail.com>
Date: Wed, 27 May 2020 11:30:14 +0200
From: Bram Bonné <brambonne@...gle.com>
To: David Miller <davem@...emloft.net>
Cc: Lorenzo Colitti <lorenzo@...gle.com>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Jakub Kicinski <kuba@...nel.org>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Linux NetDev <netdev@...r.kernel.org>,
Jeffrey Vander Stoep <jeffv@...gle.com>,
Maciej Żenczykowski <maze@...gle.com>
Subject: Re: [PATCH] ipv6: Add IN6_ADDR_GEN_MODE_STABLE_PRIVACY_SOFTMAC mode
On Wed, May 20, 2020 at 8:33 PM David Miller <davem@...emloft.net> wrote:
>
> From: Bram Bonné <brambonne@...gle.com>
> Date: Wed, 20 May 2020 15:16:53 +0200
>
> > Trying to change the MAC when the device is up errors with EBUSY on my
> > machines, so I was under the assumption that the device needs to be
> > down to change the MAC. I could very well be wrong though.
>
> Not all drivers/devices have this limitation, the generic code allows this
> just fine.
>
Thanks David. I was able to test the behavior of changing the MAC
while connected to a network. It does not seem to trigger address
generation, leaving the link-local address intact.
Do we know about any scenarios (apart from dev reconfiguration) that
would trigger address generation? My understanding based on the code
is that any other scenario would add an additional link-local address,
rather than removing the old one.
Powered by blists - more mailing lists