Hide Forgot
Description of problem: Fedora gets ipv6 address, this address drops in a few minutes and only ipv6 LL address remains. After disconnecting the cable and connecting back, ipv6 address is back, but after few minutes is lost again. Every connection made in ipv6 is broken after ipv6 address disappers. Version-Release number of selected component (if applicable): fedora 20, 64bit, 3.11.10-301.fc20.x86_64 How reproducible: use fedora20 final release Steps to Reproduce: 1. get ipv6 2. make some ipv6 connection, wait for ipv6 drop 3. cable dis/connect and wait for new ipv6 and the problem will repeat again Actual results: ipv6 unusable Expected results: ipv6 works fine as in fedora19 or any other distro
This certainly has nothing to do with kdenetwork, reassigning to kde-plasma-nm for now, but I suspect NetworkManager itself.
Probably an issue in NetworkManager.
I'm seeing this as well, except that in my case it only seems to happen every 24 hours or so. I ran NM with logging set to debug for the last 36 hours or so, but I can't see anything obvious at the point where it dropped the address this afternoon.
Created attachment 838706 [details] NetworkManager log This is the NM log from around the time when I last lost my IPv6 address. The restart at 15:46:11 is when I got an alert and restarted NM to get the address back - it was probably lost around 5-10 minutes before that. One thing I did notice is that when I restarted it and it did the router solicitation it logged this: Dec 18 15:46:11 bericote.compton.nu NetworkManager[17199]: <debug> [1387381571.814253] [rdisc/nm-lndp-rdisc.c:447] receive_ra(): Recieved router advertisement: 7 at 355431 Dec 18 15:46:11 bericote.compton.nu NetworkManager[17199]: <debug> [1387381571.814291] [rdisc/nm-rdisc.c:105] config_changed(): (br0): router discovery configuration changed [dGAR]: Dec 18 15:46:11 bericote.compton.nu NetworkManager[17199]: <debug> [1387381571.814299] [rdisc/nm-rdisc.c:106] config_changed(): dhcp-level none Dec 18 15:46:11 bericote.compton.nu NetworkManager[17199]: <debug> [1387381571.814305] [rdisc/nm-rdisc.c:111] config_changed(): gateway fe80::21c:c0ff:fede:937a pref 2 exp 357231 Dec 18 15:46:11 bericote.compton.nu NetworkManager[17199]: <debug> [1387381571.814313] [rdisc/nm-rdisc.c:117] config_changed(): address 2001:8b0:bd:1:2b0:c2ff:fe02:4cf3 exp 441831 Dec 18 15:46:11 bericote.compton.nu NetworkManager[17199]: <debug> [1387381571.814327] [rdisc/nm-rdisc.c:123] config_changed(): route 2001:8b0:bd:1::/64 pref 0 exp 441831 Dec 18 15:46:11 bericote.compton.nu NetworkManager[17199]: <info> Activation (br0) Stage 5 of 5 (IPv6 Commit) scheduled... Dec 18 15:46:11 bericote.compton.nu NetworkManager[17199]: <debug> [1387381571.814360] [rdisc/nm-lndp-rdisc.c:346] check_timestamps(): Scheduling next now/lifetime check: 357231 seconds Which talks (in the last line) about doing a check in 357231 seconds, or 99 hours, which seems quite a long time. My radvd is using the default lifetimes for everything.
> Dec 18 15:30:01 bericote.compton.nu NetworkManager[25701]: <debug> [1387380601.805886] [settings/nm-agent-manager.c:1477] agent_permissions_changed_done(): (:1.54/org.gnome.Shell.NetworkAgent/1000) updated agent permissions (note the "org.gnome.Shell" part) So this proves this is a general NetworkManager issue and not KDE-specific. Thanks for your report and log! The NetworkManager developers may find some other interesting information in the log.
Also I notice from wireshark that 86400 seconds is the maximum prefix lifetime my radvd is announcing which matches the once a day loss of address. Maybe the original reporter can confirm if his prefix lifetime is shorter?
Yes, I can confirm shorter lifetime - 7200 seconds and this is the time of desappearing the ipv6 address. Seems NM is not able to renew the address.
probably related: #1045746
It appears this is being tracked in bug 1044757
No the router solicitation loop in bug 1044757 is a separate issue.
after NM upgrade - by yum update - it seems ipv6 is ok, I tested it today and ipv6 internet was functional and ipv6 did not disappear.
I think this issue is fixed upstream with commit http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=5ec9b9e97c1e1647c7bb45c79518f1c49cb23cd6 It is present in NM 0.9.9.x since the beginning, and will be fixed with the upcoming release https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-32.git20131003.fc20
NetworkManager-0.9.9.0-32.git20131003.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-32.git20131003.fc20
Package NetworkManager-0.9.9.0-32.git20131003.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.9.0-32.git20131003.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-4039/NetworkManager-0.9.9.0-32.git20131003.fc20 then log in and leave karma (feedback).
NetworkManager-0.9.9.0-32.git20131003.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
I have serious problems with ipv6 again since the latest update. In Fedora 19 everything was stable, but since release 20 I see problems with ipv6 e.g. for ipv6 enabled websites like facebook. The website is only accessable if I disable ipv6 on the network interface. This happens on both of my fedora 20 machines. Maybe related, I see also serious problems when multiple interfaces are up (e.g. Wifi and ethernet). If my laptop has wifi enabled and no network cable connected, everything works fine, until I plug in the network cable. Then I get timeout errors when accessing websites. When I disable Wifi then suddenly network traffic is sane again. It looks to me that NetworkManager does not work well when there are multple ways to communicate (ipv4 via wifi or ipv4 via ethernet or ipv6 via wifi or ipv6 via ethernet). Let me know if I can help debugging.
This bug was (as all good bugs should be) a specific problem where the address was not renewed properly. If you are having a problem, and it sounds like an entirely different problem, then you should open your own bug where that problem can be isolated and addressed, not comment on an existing bug which is only marginally related (and is closed anyway).
Ok, good to know it is another type of problem. I reported the problem three months ago (bug 1045746), but it has not gotten any attention.