Bug 233757 - IPv6 addresses on physical dev are all flushed when disconnecting from VPN
IPv6 addresses on physical dev are all flushed when disconnecting from VPN
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
8
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-24 14:22 EDT by Daniel Berrange
Modified: 2009-01-08 23:36 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-08 23:36:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Re-add an ipv6 link address after disconnecting from VPN (743 bytes, patch)
2007-03-24 14:25 EDT, Daniel Berrange
no flags Details | Diff
Re-add IPv6 link-local address when disconnecting VPN (NM 0.7.0) (632 bytes, patch)
2007-12-15 15:05 EST, Daniel Berrange
no flags Details | Diff

  None (edit)
Description Daniel Berrange 2007-03-24 14:22:50 EDT
Description of problem:
When initializing the physical device (eth0/eth1) NetworkManager adds an ipv6
link local address. My LAN is running radvd so the device shortly also
auto-configures itself a ipv6 global addresse & route, so I have full IPv6
connectivity to the Internet at this point.

I then start VPNC to connect to the office VPN. This adds a tun0 and re-routes
IPv4 traffic for certain IPv4 subnets. My global IPv6 address / connectivity on
the physical device (eth0/eth1) is unaffected at this time - it continues to
operate independant on the IPv4 VPN connection.

Now I disconnect from the office VPN, which removes the tun0 device, but *also*
appears to flush all IPv6 addresses from my underlying physical device
(eth0/eth1) so I loose all IPv6 connectivity. This is obviously sub-optimal,
since there is absolutely no need to touch IPv6 addresses/routes when
de-configuring an IPv4 VPN connection.

Version-Release number of selected component (if applicable):
NetworkManager-0.6.4-5.fc6

How reproducible:
Always

Steps to Reproduce:
1. Connect machine (with wifi/ethernet) to a network which is IPv6 enabled with
a globally routed address prefix. ie a LAN with an radvd which advertises a
prefix for a subnet somewhere under 2000::/3 
2. Wait for NetworkManager to configure the eth0/eth1
3. Run ifconfig ethX  for your physical device
4. Observe IPv6 addresses:

# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:15:58:2F:E9:55  
          inet addr:192.168.254.132  Bcast:192.168.254.255  Mask:255.255.255.0
          inet6 addr: 2001:4830:1104:1:215:58ff:fe2f:e955/64 Scope:Global
          inet6 addr: fe80::215:58ff:fe2f:e955/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2832 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2385 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:2856220 (2.7 MiB)  TX bytes:331165 (323.4 KiB)
          Base address:0x3000 Memory:ee000000-ee020000 

5. Connect to a VPN  (in my case using NetworkManager VPNC plugin)
6. Run ifconfig ethN  again & observe IPv6 addresses are still present
7. Verify IPv6 connectivity by visiting 'www.kame.net' in firefox & looking for
an animated turtle graphic.
8. Disconnect from the VPN
9. Run ifconfig ethN  again & observe the lack of IPv6 addresses:

# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:15:58:2F:E9:55  
          inet addr:192.168.254.132  Bcast:192.168.254.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2832 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2385 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:2856220 (2.7 MiB)  TX bytes:331165 (323.4 KiB)
          Base address:0x3000 Memory:ee000000-ee020000 

10. Shift+refresh the firefox page www.kame.net & observe the turtle is no
longer animated - indicating you're connecting over IPv4 :-(

Actual results:
NetworkManager flushes all IPv6 addresses upon VPN disconnect

Expected results:
NetworkManager  leaves IPv6 addresses alone, or explicitly recreates them after
flushing them.

Additional info:
Running strace on the NetworkManager processes I can see that when disconnecting
from the VPN it runs

  ip addr flush eth1
  ip route flush eth1

This flushes both IPv4 & IPv6 addresses from the device.

After poking around in the code I find:


$ grep --after 20 src/nm_vpn_connection_deactivate vpn-manager/nm-vpn-connection.c
void nm_vpn_connection_deactivate (NMVPNConnection *connection)
{
        g_return_if_fail (connection != NULL);

        if (connection->vpn_iface)
        {
                nm_system_device_set_up_down_with_iface (connection->vpn_iface,
FALSE);
                nm_system_device_flush_routes_with_iface (connection->vpn_iface);
                nm_system_device_flush_addresses_with_iface (connection->vpn_iface);
        }

        if (connection->ip4_config)
        {
                /* Remove attributes of the VPN's IP4 Config */
                nm_system_vpn_device_unset_from_ip4_config
(connection->named_manager, connection->parent_dev,
                                connection->vpn_iface, connection->ip4_config);

                /* Reset routes, nameservers, and domains of the currently
active device */
                nm_system_device_set_from_ip4_config (connection->parent_dev);
        }

This last line above 'nm_system_device_set_from_ip4_config' is what causes the
addresses to all be flushed & IPv4 re-initialized.

In other places which call 'nm_system_device_set_from_ip4_config' -eg 
nm-device.c  - the call is followed by a call to
nm_system_device_add_ip6_link_address  which enables IPv6 autoconf on the device.

Thus the minimal effort fix is to add a call to
nm_system_device_add_ip6_link_address in the nm_vpn_connection_deactivate method.
Comment 1 Daniel Berrange 2007-03-24 14:25:39 EDT
Created attachment 150833 [details]
Re-add an ipv6 link address after disconnecting from VPN

This patch implements the minimal effort fix to make IPv6 work after
disconnecting from the VPN. It explicitly configures an IPv6  link local
address after the interface has been flushed. The kernel will then shortly do
auto-configuration to pick up a global address restoring full IPv6
connectivity.
Comment 2 Daniel Berrange 2007-12-15 15:05:38 EST
Created attachment 289704 [details]
Re-add IPv6 link-local address when disconnecting VPN (NM 0.7.0)

This is still broken in Fedora 8. Updated the patch to apply against
NetworkManager 0.7.0  in Fedora 8
Comment 3 mike taht 2008-03-30 03:24:00 EDT
Why do you have to flush the ipv6 information at all? 

Taking the device completely offline and then restoring breaks all local ipv6
connections (ssh for example, a tunnel for another, and I'm trying to figure out
why olsr is going south).

See also: http://the-edge.blogspot.com/2008/03/ipsec-over-ipv6-for-olpc.html
for a bit more detail.

Apologies for being a little testy in that blog post and for this not quite
being the same bug, although it looks like it is happening in the same place. I
will dig into the nm code some to find enlightenment. 
Comment 4 Bug Zapper 2008-11-26 02:12:47 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Bug Zapper 2009-01-08 23:36:09 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.