disconnecting PPTP and OPENVPN VPN in NM causes libnl backend module to get stuck in OFFLINE

[Alexander Sack]

disconnecting a network-manager managed VPN (over a wifi link - wlan0) causes ntrack to sometimes not come back from OFFLINE to ONLINE state. Also RECONNECT event isn't reliably emitted after connecting with natty network-manager to VPN. needs to be fixed for 015

[Alexander Sack (asac)]

after disconnecting it seems that libnl cache managers get into a bad state where oif for the topmost 0.0.0.0 route (and nexthop if for libnl >= 2) is NULL.

route -n shows proper interface for the routes, so I believe its libnl cache manager that has a problem keeping up.

also it seems that RECONNECT event is not always emitted when NM adds a VPN default route. No idea yet whats happening under the hood, so could be its a different bug.

[Alexander Sack (asac)]

from what i can tell the new rtnetlink backend in ntrack 015 fixed this issue. Its not the default backend yet (but shipped as experimental), so I will keep this one open until we do the switch to rtnetlink alltogether.

you can try out through ./configure --enable-backend=rtnetlink in ntrack 015

[Alexander Sack (asac)]

reproduced this with openvpn all default routes with libnl-route-3.0 > 3.1

[Alexander Sack (asac)]

tried to tackle this again; might have another idea, but think will switch default module to rtnetlink and lower priority on this one further...

[Alexander Sack (asac)]

wow, in the end I think I really fixed this bug. I didn't think I would try fixing libnl backend ever, but here we go. Give it a try. Will bake a release after testing this for a bit...

------------------------------------------------------------
revno: 372
fixes bug: https://launchpad.net/bugs/770390
committer: Alexander Sack <email address hidden>
branch nick: ntrack
timestamp: Tue 2014-10-28 00:52:45 +0100
message:
  modules[libnl]: redo reconnect logic noticed when topmost default route changes like in case of connecting/disconnecting from VPN - fixes lp:770390

  This patch cleans up various aspects of the logic used to identify and process changes to topmost_route
  that trigger a reconnect event.

  While such logic in theory can happen often, in network-manager case we only observe this when having
  two physical cards going on and off changing the default route and when enabling and disabling VPN.