Re: Help with Ubuntu Touch update to NM 1.2

[Tony Espy <espy canonical com>]

On 05/11/2016 02:19 AM, Thomas Haller wrote:
> On Tue, 2016-05-10 at 20:49 -0400, Tony Espy wrote:
>
> Hi Tony,
>
> > After we recently landed NM 1.1.93 to Ubuntu 16.04 desktop, I
> > started
> > working on back-porting it to Vivid/15.04 for use by Ubuntu Touch
> > which
> > is still currently pinned to a 0.9.10 version of NM.
> >
> > Very little needed to be changed to get it running.
> >
> > One thing to note is that most of the devices running Touch are on
> > older
> > kernels ( mako is the oldest at 3.4, some are 3.10 ), so all output
> > the
> > message:
> >
> > 18:19:56 <warn> device (wlan0): The kernel does not support extended
> > IFA_FLAGS needed by NM for IPv6 private addresses. This feature is
> > not
> > available
>
> In the very past, NM used kernel to do autoconf (accept_ra). Already in
> 0.9.10, NM switched to using libndp and do it in user-space.
>
> That originally broke IPv6 private addresses, and it was not fixed
> until kernel added IFA_F_MANAGETEMPADDR. Thus, on your 0.9.10, IPv6
> temporary addresss are not working already know (or do they?)

Thanks for the reply Thomas!

As mentioned, we currently don't perform in-depth IPv6 testing on touch, 
so it's very likely that temp addresses have never worked properly.

> It's only that NM now warns about that...

OK

> > During testing, we ran into problems with OpenVPN that seem to be
> > related to the re-factored netlink logic in NMLinuxPlatform and the
> > older kernels we're running.
> >
> > We see two failures, the first occurs when the VPN connection
> > triggers
> > an IPv6 address add.  As the VPN specifies a unique Internal Address
> > and
> > Internal Point to Point address (or peer address), the latter is used
> > by
> > NM to build the IFA_ADDRESS attribute appended to the NEWADDR
> > message.
> > The kernel rejects this with EINVAL.
> >
> > Running 0.9.10x, the address is added, it just doesn't include the
> > peer
> > address, and uses address for the IFA_ADDRESS attribute.
> >
> > We also see quite a few of the same types of add IPv6 address
> > failures
> > happening on a periodic basis with no VPN involved, which are
> > probably
> > triggerd by lease renewals.
> >
> > I was able to patch 1.1.93 to mimic the 0.9.10 behavior ( ie. never
> > use
> > peer_address for IFA_ADDRESS ) and the errors in syslog
> > disapper.  That
> > said, I'm not 100% the IPv6 configuration was ever *working*
> > properly,
> > however with this path our syslog isn't flooded with errors.
>
> (just repeating what I said yesterday on IRC, for the list)
>
>
> Older kernels don't support peer-addresses for IPv6. That was added
> AFAIS by
>    
> http://kernel.opensuse.org/cgit/kernel-source/commit/?h=rpm-3.0.101-0.42&id=3064034a633f0e8fcb59d3c5c7514eb9ff975da6
> before, IFA_LOCAL and IFA_ADDRESS cannot differ.
>
> With 1.2, nm-openvpn tells NetworkManager to consider the peer when
> adding an IPv6 addresss. This was not present in 0.9.10 either, it was
> added by commit
>    https://git.gnome.org/browse/network-manager-openvpn/commit/?id=3ca7a54805994fd61237b8e54c08b2ed6b70f1e6
> (grep for "ifconfig_ipv6_remote")
>
>
> Unfortunately, it's not easily possible to detect at runtime whether
> kernel support it or not.
>
>
> I am not sure that patching nm-linux-platform.c to silently ignore the
> peer is correct. Maybe it's better to patch nm-openvpn (and all
> componnets) not to set IPv6 peer-addresses...
> After all, if nm-openvpn requests to add such a IPv6 address,
> NetworkManager/kernel should either comply or fail.
> I dunno at which place this should be fixed.

After some discussion this morning, we're going to back out this portion 
of the patch.

> > The second failure is adding an IPv4 address that already
> > exists.  The
> > old code base had explicit handling for this case ( EEXISTS ) and
> > would
> > treat the operation as SUCCESS.  When I added extra logic to handle
> > EEXISTS in do_add_addroute ( in nm-linux-platform.c ), the IPv4
> > error
> > also disappeared, and I found that the VPN was now properly
> > configured.
> >
> > On some of our newer devices, this IPv4 error doesn't occur, however
> > the
> > workaround appears to be a no-op on these devices.
>
>
> Why does that happen? NM sets the netlink flags to NLM_F_CREATE|NLM_F_REPLACE, so kernel should replace the 
> existing
> address.
> Which kernel version are you using precisely (which Ubuntu package)?

It happens because we're using kernels based on the Android BSPs for the 
hardware.

This only fails on some of the older devices we support ( eg. mako, 
krillin ).  Devices with newer kernels and/or from different ODMs don't 
exhibit this behavior.

In this case, without this patch, OpenVPN is broken, so we're going to 
include this in our update, as on newer devices, the error won't be 
returned.

> Does `make check` pass? Let's first add a test that shows the failure.

Yes, our PPA builds run `make check` and no failures are reported.

Regarding adding a test, yes that sounds like a good first step.

Regards,
/tony


At this