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

Bug #770390 reported by Alexander Sack on 2011-04-25
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ntrack
High
Alexander Sack

Bug Description

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

Related branches

Alexander Sack (asac) wrote :

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.

Changed in ntrack:
status: New → Triaged
importance: Undecided → High
milestone: none → 015
assignee: nobody → Alexander Sack (asac)
Alexander Sack (asac) on 2011-04-25
description: updated
description: updated
Alexander Sack (asac) on 2011-06-11
summary: - disconnecting VPN causes ntrack to get stuck in OFFLINE state
+ disconnecting PPTP VPN in NM causes ntrack to get stuck in OFFLINE state

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

Changed in ntrack:
milestone: 015 → 016
status: Triaged → In Progress
Alexander Sack (asac) on 2011-11-13
Changed in ntrack:
milestone: 016 → 017
Alexander Sack (asac) wrote :

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

summary: - disconnecting PPTP VPN in NM causes ntrack to get stuck in OFFLINE state
+ disconnecting PPTP and OPENVPN VPN in NM causes libnl backend module to
+ get stuck in OFFLINE
Alexander Sack (asac) wrote :

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) wrote :

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.

Changed in ntrack:
status: In Progress → Fix Committed
Alexander Sack (asac) on 2014-11-08
Changed in ntrack:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers