Bugzilla – Bug 778434
network with wired interface managed by networkmanager is unreliable
Last modified: 2014-07-09 20:14:05 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.
Freek, So do you use the KDE? And could attach your /var/log/NetworkManager when you met this issue? Thanks!
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.
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.
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.
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.
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.
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
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.
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.
*** Bug 785232 has been marked as a duplicate of this bug. ***
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.
(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.
(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.
(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.
Problem no longer present in 13.2 (factory).