[cert-v2] tun_linux.go: retry setting default MTU

[JackDoanRivian]

No description provided.

[nbrownus]

The ordering of Activate changed a good deal, have we tried moving it back to the order it was in to see if that helps this situation?

nebula/overlay/tun_linux.go

Lines 328 to 352 in e264a0f

	ifrf.Flags = ifrf.Flags | unix.IFF_UP
	if err = ioctl(t.ioctlFd, unix.SIOCSIFFLAGS, uintptr(unsafe.Pointer(&ifrf))); err != nil {
	return fmt.Errorf("failed to bring the tun device up: %s", err)
	}
	link, err := netlink.LinkByName(t.Device)
	if err != nil {
	return fmt.Errorf("failed to get tun device link: %s", err)
	}
	t.deviceIndex = link.Attrs().Index
	if err = t.setDefaultRoute(); err != nil {
	return err
	}
	// Set the routes
	if err = t.addRoutes(false); err != nil {
	return err
	}
	// Run the interface
	ifrf.Flags = ifrf.Flags | unix.IFF_UP | unix.IFF_RUNNING
	if err = ioctl(t.ioctlFd, unix.SIOCSIFFLAGS, uintptr(unsafe.Pointer(&ifrf))); err != nil {
	return fmt.Errorf("failed to run tun device: %s", err)
	}

[JackDoanRivian]

I fiddled with the ordering and it didn't seem to make a difference.

I think the problem we're seeing here is somehow caused by having more than one IP -- especially an IPv6 IP. When I test with single-IP certs I'm completely unable to reproduce the problem.

[JackDoanRivian]

Oh also, when this fails it always fails when adding the second route. The first route always works.