[CRIU] [PATCH 3/5] net: c/r ipv6 addresses for links

[Andrew Vagin]

On Tue, Nov 24, 2015 at 08:41:57AM -0700, Tycho Andersen wrote:
> On Tue, Nov 24, 2015 at 12:22:59PM +0300, Andrew Vagin wrote:
> > On Mon, Nov 23, 2015 at 01:55:26PM -0700, Tycho Andersen wrote:
> > > Here's a start at checkpoint/restore of links with ipv6 addresses. Each
> > > link can have more than one ipv6 address:
> > > 
> > > eth0      Link encap:Ethernet  HWaddr 1c:6f:65:d5:56:98
> > >           inet addr:192.168.0.69  Bcast:192.168.0.255  Mask:255.255.255.0
> > >           inet6 addr: fe80::1e6f:65ff:fed5:5698/64 Scope:Link
> > >           inet6 addr: fd5d:e5bb:c5f9::c0c/128 Scope:Global
> > >           inet6 addr: fd5d:e5bb:c5f9:0:1e6f:65ff:fed5:5698/64 Scope:Global
> > >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> > >           RX packets:63439992 errors:0 dropped:0 overruns:0 frame:0
> > >           TX packets:44446651 errors:0 dropped:0 overruns:0 carrier:0
> > >           collisions:0 txqueuelen:1000
> > >           RX bytes:56986160322 (56.9 GB)  TX bytes:20927902606 (20.9 GB)
> > > 
> > > This patch doesn't dump any flags right now (and only restores with NODAD), but
> > > I don't know enough about ipv6 to say how to c/r flags, or even if anything is
> > > needed.
> > 
> > We use "ip addr save" to dump addresses and it works for ipv4. Why this
> > doesn't work for ipv6?
> 
> It can, but stuff like DAD means that we may have to wait for a long
> time to actually use the addresses, since you can't bind() to an
> address that has the TENATIVE flag. Since we are binding to an ipv6
> link local address by default in xenial ubuntu images, I was hitting
> this.

I think I've fixed this issue here:
https://github.com/xemul/criu/commit/73a739b8d372444186fd25089a34a7fada7e0b94

> 
> For a while I had an implementation that just waited for the flag to
> clear, but that can take a few seconds and we probably don't want to
> do that in the hot path of restore. I could see about adding a
> --set-nodad flag on ip addr restore instead, though.
> 
> Tycho