Re: Help with Ubuntu Touch update to NM 1.2



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?)

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



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.






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)?

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


At minimum, the second problem is a blocker for our next update.  We 
could probably live without the peer_address change, however as
stated, 
it results in failures being logged.

I've attached a sanitized syslog which shows the errors in question
when 
a VPN is started.

Any help is much appreciated.

Regards,
/tony

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]