GNOME Bugzilla – Bug 685040
WiFi connection with IPv6 unstable
Last modified: 2012-10-16 21:15:34 UTC
Created attachment 225332 [details] NetworkManager log file I connect with my laptop using NetworkManager with a wifi connection to a router with native IPv6 support. The connections is established and the interface gets an IPv4 address via DHCP and a global IPv6 address via automatic configuration. The router does not have a DHCP6 server enabled. After a short period, a few minutes, the connection fails and needs to be restarted. I use "systemctl restart network.service". After that there is a connection for a short period after which it fails again. This is only a problem when having a connection with my router with native IPv6 enabled. When I connect to another router with only IPv4 the connections is stable. I am using NetworkManager version 0.9.4.0 In the attached log file at 09:52 the system is started and the connection is established. At 09:54 the connection seems to disappears. Don't know what the log show afterwards. At 10:38 the network has been restarted. At 10:51 again a network restart.
Also a wired connection connected to a router with IPv6 without a DHCP6 server managed by NetworkManager is unstable. In that case however, the connections is gone for about 15 seconds and establishes itself again. The connection is disconnected after the 45 seconds timeout of the DHCP6 client. In one case this means that the connection is there for about 45 seconds after which it reestablishes itself in about 15 seconds. In another VM system with the same setup the connections stays for several minutes
Please test with NetworkManager 0.9.6. A bunch of IPv6-related bugs have been fixed. Playing with NetworkManager prior to 0.9.6 and IPv6 is rather pointless. For your testing, please disable IPv6 firewall (or check if it doesn't drop anything related to IPv6 confugiration). And run NM manually with --no-daemon and --log-level=debug. But be prepared for lots of information that don't look very useful.
I did build version 0.9.7 from the git repository and tested it, however not with any extra debug output. With a filter allowing IPv6 packets to UDP port 564 the connection is fully stable. It does not generate any line in the log file after the lines from the start up.
Thanks!
There is one point that still concerns me. When I don't use NetworkManager and I do not have the filter to allow the IPv6 packets to UDP port 564 the connection I get is stable. So I wonder why the connection is not stable when I use NetworkManager with a standard firewall set up. Note that my router does not have a DHCPv6 server running. I did not enable that service in the router, so the IPv6 address my interface gets is from Stateless Autoconfiguration. In my view NetworkManager should not require any answer from a DHCPv6 server and should accept that the DHCPv6 client does not get an answer. So maybe there should be parameter telling NetworkManger that DHCPv6 should not be used. This should be the default. One has to explicitly configure NetworkManager to use DHCPv6 in which case that answer is required.
> So I wonder why the connection is not stable when I > use NetworkManager with a standard firewall set up. Are you sure? If yes, then it means the DHCPv6 transaction fail causes the connection to tear down. And that might be actually wrong, as this situation is too common to fail. > Note that my router does not have a DHCPv6 server running. I did not enable > that service in the router, so the IPv6 address my interface gets is from > Stateless Autoconfiguration. Then it's not doing any DHCPv6. The problem may be well in your testing. It would be great if you can make sure the firewall is actually what makes difference. I would be surprised. > In my view NetworkManager should not require any > answer from a DHCPv6 server and should accept that the DHCPv6 client does not > get an answer. Whether NM is trying to do DHCPv6 is set up by router advertisements. Could you check with tcpdump -vv or radvdump whether AdvManagedFlag and AdvOtherConfigFlag are on or off? If one of them is on, NetworkManager is required to cunsult the DHCP server. The transaction can fail badly (tear down the connection), fail gracefully (check if IPv6 configuration is required and only fail if it is) or even ignore the problem, which I don't particularly like. I guess your network is most probably misconfigured. The only question is how to handle that situation. The other problem is in the kernel that doesn't match DHCPv6 replies to DHCPv6 requests and this is worked around by some firewall scripts or daemons. > So maybe there should be parameter telling NetworkManger that > DHCPv6 should not be used. This is determined by the router. We could add a tweak to ignore router administrators decision for advanced users, though. > This should be the default. No. By default we should adhere to the IETF standards and do what's required for successful IPv6 configuration. > One has to explicitly configure NetworkManager to use DHCPv6 in which case that answer is required. No. Same as above. Reopening so that we can try to resolve this.
(In reply to comment #6) > > So I wonder why the connection is not stable when I > > use NetworkManager with a standard firewall set up. > > Are you sure? If yes, then it means the DHCPv6 transaction fail causes the > connection to tear down. And that might be actually wrong, as this situation > is too common to fail. > > > Note that my router does not have a DHCPv6 server running. I did not enable > > that service in the router, so the IPv6 address my interface gets is from > > Stateless Autoconfiguration. > > Then it's not doing any DHCPv6. The problem may be well in your testing. It > would be great if you can make sure the firewall is actually what makes > difference. I would be surprised. Apparently I did enable the DHCPv6 server in my router. Sorry about that. So I disabled the DHCPv6 server and now with 0.9.7 the connection is stable with a standard firewall. However with the DHCPv6 server enabled, and with a standard firewall the connection is not stable. I have three options to enable DHCPv6. I tried all three and in none of these cases the connection is stable. I have to allow packets to UPD port 546 to get a stable connection. > > In my view NetworkManager should not require any > > answer from a DHCPv6 server and should accept that the DHCPv6 client does > > not get an answer. Sorry not applicable > Whether NM is trying to do DHCPv6 is set up by router advertisements. Could > you check with tcpdump -vv or radvdump whether AdvManagedFlag and > AdvOtherConfigFlag are on or off? I attach a libpcap file catched with wireshark and filtered to contain only ICMPv6 and DHCPv6 packets. At the moment wireshark was activated the DHCPv6 server was active and the packets to UDP port 546 were blocked by the firewall, so the DHCPv6 client timed out after 45 seconds and NM restarted the connection. Somewhat later I allowed these packets in the firewall and the connection became stable. I could not find these names AdvManagedFlag and AdvOtherConfigFlag in wireshark, so I hope the attachment answers your question.
Created attachment 225899 [details] libpcap formatted file with ICMPv6 and DHCPv6 packets In the beginning of the capture packets to UDP port 546 are not allowed by the firewall. In this case after 45 seconds timeout of the DHCPv6 client NM restarts the connection. Later these packets are allowed and the DHCPv6 client does not time out and the connection becomes stable.
> Apparently I did enable the DHCPv6 server in my router. Sorry about that. No problem. > So I disabled the DHCPv6 server and now with 0.9.7 the connection is stable > with a standard firewall. That's good. > However with the DHCPv6 server enabled, and with a standard firewall the > connection is not stable. Kernel doesn't support DHCPv6 packet matching and your firewall doesn't work around it. It really should. Therefore you don't get the DHCP answer and the IPv6 configuration is bound to fail. > I have three options to enable DHCPv6. A useful information would be the actual router advertisement caught by tcpdump -vv or radvdump. Otherwise nobody knows what and why are the three ways on your router. > I tried all three and in none of these cases the connection is stable. The connection fails because of failed IPv6 configuration. You would maybe expect to continue IPv4-only. But you haven't said it expicitely, therefore we can only guess. > I have to allow > packets to UPD port 546 to get a stable connection. You have to recieve DHCPv6 packets ot have a DHCPv6 configuration. > > Whether NM is trying to do DHCPv6 is set up by router advertisements. Could > > you check with tcpdump -vv or radvdump whether AdvManagedFlag and > > AdvOtherConfigFlag are on or off? > > I attach a libpcap file catched with wireshark and filtered to contain only > ICMPv6 and DHCPv6 packets. At the moment wireshark was activated the DHCPv6 > server was active and the packets to UDP port 546 were blocked by the firewall, > so the DHCPv6 client timed out after 45 seconds and NM restarted the > connection. Sounds like what I have written above. > Somewhat later I allowed these packets in the firewall and the > connection became stable. As IPv6 configuration was then possible. > I could not find these names AdvManagedFlag and AdvOtherConfigFlag in > wireshark, so I hope the attachment answers your question. Your attached dump shows a successful DHCPv6 exchange. I actually need to know whether the only thing you complain about is that NetworkManager doesn't fall back gracefully to IPv4-only when you fail to provide a working IPv6/DHCPv6 environment (including your host firewall).
When NM detects the timeout from the DHCPv6 client, the whole connections is restarted although the IPv4 connection is OK. Besides, the IPv6 connection is also OK. I still can make an outside connection with IPv6 except naturally when the interface is reestablished after the DHCPv6 client timeout. When I look with "ip addr" at the interface in any case I don't see any difference. I get a global IPv6 address derived from the MAC address of the interface and apparently the default gateway is OK as well. Can't tell about the DNS, where the IPv4 address can be used.
> When NM detects the timeout from the DHCPv6 client, the whole connections is > restarted although the IPv4 connection is OK. Correct. This is the current behavior. > Besides, the IPv6 connection is also OK. Nope. We are implementing IPv6 automatic configuration according to the IETF standards. There is a difference between. > I still can make an outside connection with IPv6 In some special cases, yes. Otherwise, if you are using DHCPv6 for address configuration and you don't recieve a reply, you don't recieve the IPv6 address. NetworkManager *must* recognise this failure. > When I look with "ip addr" at the interface in any case I don't see any > difference. Because your testing environment is nonstandard. If you are careful to have clean interfaces before NetworkManager starts, and if you are careful to setup the router to disallow stateless automatic configuration (AdvAutonomous in the prefix section of radvd), you will not get an IP address. > I get a global IPv6 address derived from the MAC address of the > interface and apparently the default gateway is OK as well. Therefore your network configuration allows for autonomous addressing and requires DHCP addressing at the same time. If all you want is a MAC-derived address, you should disable DHCP address configuration on the router advertisement daemon (e.g. in radvd it is AdvManaged). > Can't tell about the DNS, where the IPv4 address can be used. Please refer to the following use cases: https://fedoraproject.org/wiki/Tools/NetworkManager/IPv6 The IPv6 configuration can *only* be considered successful either if DHCP configuration is not required according to router advertisement, or if it is successful. Refusing to follow the internet standards is generally not a good way.
After reading a lot in the RFCs I found that in two of the three cases when I enable DHCP in the router, RA only sets the AdvOtherConfigFlag in which case DHCPv6 provides the DNS. The second of the two is to enable prefix delegation. In the third case both AdvManagedFlag and AdvOtherConfigFlag are set and the server provides the MAC address derived IPv6 address. Currently the router is not capable to provide other, management configured, IPv6 addresses. The conclusion is that NM works as it should in this respect. The problem is/was in firewall not passing on the UDP port 546 packets.
> In the third case both AdvManagedFlag and AdvOtherConfigFlag are set and the > server provides the MAC address derived IPv6 address. The server can't derive IPv6 from MAC according to the DHCPv6 RFC. > The conclusion is that NM works as it should in this respect. Good. > The problem is/was in firewall not passing on the UDP port 546 packets. That's it. Thanks.
(In reply to comment #13) > > In the third case both AdvManagedFlag and AdvOtherConfigFlag are set and the > > server provides the MAC address derived IPv6 address. > > The server can't derive IPv6 from MAC according to the DHCPv6 RFC. But this is what the server does. Isn't the server free to provide any address as long as it is unique and has the proper prefix. The client just asks for a global non-temporarely IPv6 address and the server provides this address, which is accepted by the client. I asked the manufacturer more information on this.
I repeated the test with the DHCPv6 server also providing the IPv6 address. Now the REPLY from the server is NoAddrAvail. However the interface does have a global IPv6 address during the time the DHCPv6 client is awaiting the REPLY (from Stateless Address Autoconfiguration using the MAC address). After the 45 seconds timeout of the DHCPv6 client, NM clears the interface and starts to initialize the interface again, which takes about 5 seconds. So what I see when do each second a ping6, either to the router or to an outside IPv6 address, is about 45 pings OK and about 5 pings "Network is unreachable". Reading the RFC it is not quite clear to me whether this Stateless Address Autoconfiguration for the global address is allowed to be performed when the RA specifies the M bit. So is there a bug in this area? At least it is not a bug in NM. However I would expect the DHCPv6 client to issue a status message about NoAddrAvail and NM to reflect that in a message.
> But this is what the server does. Isn't the server free to provide any address > as long as it is unique and has the proper prefix. But there's no MAC address in IPv6 header, nor in the DHCPv6 datagram. Unless the DHCP server pokes into the lower level data or it uses NDP to discover neighbor MAC addresses, it doesn't learn it at all. > The client just asks for a global non-temporarely IPv6 address and > the server provides this address, which is accepted by the client. > I asked the manufacturer more information on this. In DHCP for IPv6 there's no MAC address in this process.
> I repeated the test with the DHCPv6 server also providing the IPv6 address. Now > the REPLY from the server is NoAddrAvail. Yep. That's the error. > However the interface does have a global IPv6 address during the time the > DHCPv6 client is awaiting the REPLY (from Stateless Address Autoconfiguration > using the MAC address). This is irrelevant to the DHCP exchange. > After the 45 seconds timeout of the DHCPv6 client, NM > clears the interface and starts to initialize the interface again, which takes > about 5 seconds. So what I see when do each second a ping6, either to the > router or to an outside IPv6 address, is about 45 pings OK and about 5 pings > "Network is unreachable". Sure, this is the current behavior. > Reading the RFC it is not quite clear to me whether this Stateless Address > Autoconfiguration for the global address is allowed to be performed when the RA > specifies the M bit. It's not forbidden, it's just unusual to use both mechanism for address configuration. > So is there a bug in this area? Nope. A big picture of reaction to various configuration errors is not covered and probably cannot be covered by the RFCs. > At least it is not a bug in NM. However I would expect the DHCPv6 > client to issue a status message about NoAddrAvail and NM to reflect > that in a message. There's always enough space to improve error reporting. But this is more in the scope of ISC DHCP client if you're using that one. I usually see everything I need from its output.