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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
