Help with Ubuntu Touch update to NM 1.2

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

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.

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.

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.


Attachment: mako-rc-434-nm-vpn.out
Description: Text document

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