Bug 778434 - network with wired interface managed by networkmanager is unreliable
network with wired interface managed by networkmanager is unreliable
Status: VERIFIED FIXED
: 785232 (view as bug list)
Classification: openSUSE
Product: openSUSE 12.2
Classification: openSUSE
Component: Network
RC 2
x86-64 openSUSE 12.2
: P5 - None : Major (vote)
: ---
Assigned To: David Liang
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-01 21:03 UTC by Freek de Kruijf
Modified: 2014-07-09 20:14 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
This is what comes in the log at the moment the connection is reset (5.34 KB, text/plain)
2012-09-03 09:34 UTC, Freek de Kruijf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Freek de Kruijf 2012-09-01 21:03:19 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0

I am running in VirtualBox an openSUSE 12.2 system which is up-to-date today September 1, 2012. So I have a picture of a UTP connector in the system tray from the applet-networkmanagement. Regularly, about once per minute, I see a red square with a white cross appear in the icon, followed by a red circle with a slanted bar through it, followed by a white bar at the bottom.
Having a ping to the router running in a console in the VM, I miss 2 or 3 pings with the error message:
ping: sendmsg: Network is unreachable
The network for the VM is set in bridge mode. The network supports both IPv4 and IPv6. The following is the output of "ip addr"
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:24:85:f8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.82/24 brd 192.168.1.255 scope global eth0
    inet6 2001:980:64c7:1:a00:27ff:fe24:85f8/64 scope global dynamic 
       valid_lft 5191sec preferred_lft 3586sec
    inet6 fe80::a00:27ff:fe24:85f8/64 scope link 
       valid_lft forever preferred_lft forever
Also a ping6 to the router and to the host of the VM shows the same behavior, about each minute the connection is down for a few seconds.

Reproducible: Always

Steps to Reproduce:
1. see above
Actual Results:  
The connection is not stable.

Expected Results:  
The connection should stay stable.
Comment 1 Bin Li 2012-09-03 08:54:36 UTC
Freek,

So do you use the KDE?

And could attach your /var/log/NetworkManager when you met this issue? Thanks!
Comment 2 Freek de Kruijf 2012-09-03 09:34:33 UTC
Created attachment 504281 [details]
This is what comes in the log at the moment the connection is reset

I tried the same with a similar system (afaik) but not in VirtualBox (in a separate partition of my disk) and did not notice this problem.
Comment 3 Freek de Kruijf 2012-09-07 12:14:44 UTC
I looked more closely in the log of NetworkManager and found that the pattern is that DHCP6 is started with a timeout of 45 seconds. About that time later there is a message that DHCP6 timed out and the interface is reset after which a few seconds later (about 5) DHCP6 is restarted.

The reason DHCP6 fails is that there is no DHCP6 server in the network, which is not required, because IPv6 can use auto configuration. So the failure for DHCP6 should just be ignored and the IPv6 parameters already received from auto configuration should be used for that interface.

However there is one problem related to auto configuration more. When not using NetworkManager auto configuration without DHCP6 obeys the default set in  /proc/sys/net/ipv6/conf/default/use_tempaddr, which is 2 (use a random generated lower 64 bits in the IPv6 address) in /proc/sys/net/ipv6/conf/eth0/use_tempaddr. When using the NetworkManager this value is 0, which uses the lower 64 bits of the IPv6 address from the MAC address. So NetworkManager should set this value to 2 if not changed in a setting in a ifsysct file(s) in /etc/sysconfig/network/ while IFSYSCTL_NETWORKMANAGER is set to yes in the config file there.
Comment 4 Freek de Kruijf 2012-09-29 11:13:14 UTC
I reported the problem also upstream. The suggestion came back that the cause could be the firewall. So I disabled the firewall in a test environment and the problem is gone. What I see in the firewall log is that packets to UDP port 5353 are blocked. So opening up the firewall for this port might solve the problem. However this opening up should be restricted to sources from the local network only. Currently I don't know how to do that. Will try to open the firewall for all packages to 5353.
Comment 5 Freek de Kruijf 2012-10-01 12:49:44 UTC
I entered the following line in /etc/sysconfig/SuSEfirewall2
FW_SERVICES_ACCEPT_EXT="fe80::/64,udp,546,547 0::/0,udp,5353,5353"
So there is a problem with the packets for DHCP6 (UDP 546 and 547) and UDP 5353 for mdns. It looks that DHCP4 packets are allowed by the firewall without any configuration, also UDP 5353 for IPv4 is open in the firewall without any manual configuration. However IPv6+UDP+546 needs to be explicitly opened in the firewall. This one can be restricted to IPv6 addresses starting with fe80::/64. However IPv6+UDP+5353 needs to be opened also for a global addresses in the local network. This needs to be done by a special parameter for the source IPv6 address range of the local network in a general fashion. In a fixed environment this can be done by something static, however for a laptop a more adaptive source address is necessary.

NOTE: This probably not enough. One most likely also needs a higher version of NetworkManager at least 0.9.6 which has bugs resolved for working in an IPv6 environment.
Comment 6 Freek de Kruijf 2012-10-03 10:58:08 UTC
I entered a related bug report about the firewall blocking UDP ports 546 and 5353 for IPv6 where these ports are more or less open in IPv4 in a standard configuration of the firewall. See bug#783002.

This report should focus on the problem in NetworkManager. Without NetworkManager the connections using IPv6 for a wired and wireless connection are stable.
Comment 7 Freek de Kruijf 2012-10-03 12:19:16 UTC
Now using NetworkManager 0.9.4 with wireless improved the situation a lot. Now the connection is automatically restored. Without a filter to allow IPv6 packets to UDP port 546, this is done about once per minute. Allowing these packets the connection is automatically restored about each 20 minutes, which is most likely caused by a bug in NetworkManager. 
See https://bugzilla.redhat.com/show_bug.cgi?id=753482
Comment 8 Freek de Kruijf 2012-10-04 21:57:04 UTC
I did build version 0.9.7 from the git repository and tested it. Now the connection stays stable all the time, provided the firewall does not block IPv6 UDP port 564. Also there are no more warnings or error messages in the log file after the full start up of NetworkManager.

So this bug report can be closed as fixed when 0.9.7 is present in a 12.2 repository.
Comment 9 Freek de Kruijf 2012-10-16 08:19:55 UTC
The upstream bug report is https://bugzilla.gnome.org/show_bug.cgi?id=685040 in which the conclusion is that NM (0.9.7) does what it is supposed to do and the only problem is in the firewall.
Comment 10 Freek de Kruijf 2012-10-17 12:20:07 UTC
*** Bug 785232 has been marked as a duplicate of this bug. ***
Comment 11 Freek de Kruijf 2012-10-17 12:23:58 UTC
Raised the priority to Major, because of bug#785232, where there is no workaround for a VPN connection, except when using NetworkManager 0.9.6 from a GNOME repository.
Comment 12 Bin Li 2012-11-15 07:05:21 UTC
(In reply to comment #8)
> I did build version 0.9.7 from the git repository and tested it. Now the
> connection stays stable all the time, provided the firewall does not block IPv6
> UDP port 564. Also there are no more warnings or error messages in the log file
> after the full start up of NetworkManager.
> 
> So this bug report can be closed as fixed when 0.9.7 is present in a 12.2
> repository.

0.9.7 will not in 12.2, we'll put it in next release.
Comment 13 Bin Li 2012-11-15 07:11:48 UTC
(In reply to comment #11)
> Raised the priority to Major, because of bug#785232, where there is no
> workaround for a VPN connection, except when using NetworkManager 0.9.6 from a
> GNOME repository.

I'm not sure which patch affects it, I'll try to backport it.
Comment 14 Freek de Kruijf 2012-11-15 15:07:39 UTC
(In reply to comment #12)
> 0.9.7 will not in 12.2, we'll put it in next release.

As mentioned above, I did build 0.9.7 without any noticed issue in 12.2, but it looks like 0.9.6 is OK also. In one system I replaced the 0.9.7 with 0.9.6 from a GNOME repository for 12.2 and I had no issue.
Comment 16 Freek de Kruijf 2014-07-09 20:14:05 UTC
Problem no longer present in 13.2 (factory).