Bug 1419461 - Privacy Extensions - stops to generate temporary addresses [NEEDINFO]
Summary: Privacy Extensions - stops to generate temporary addresses
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 27
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-06 08:56 UTC by Antonin
Modified: 2019-01-09 12:54 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-08-29 15:13:46 UTC
Type: Bug
jforbes: needinfo?


Attachments (Terms of Use)

Description Antonin 2017-02-06 08:56:26 UTC
Description of problem:

Privacy Extensions - randomly stop to renew next temporary address at the moment when "preferred_lft" counter of last preferred address gets to zero.
Outgoing network connections stop to use temporary addresses and for now use fixed address of relevant network interface.


Version-Release number of selected component (if applicable):

Fedora 25 with latest kernel - 4.9.6-200.fc25.x86_64 #1 SMP Thu Jan 26 10:17:45 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux


How reproducible:

sysctl -w net.ipv6.conf.eno1.use_tempaddr=2
sysctl -w net.ipv6.conf.eno1.temp_prefered_lft=1200 (not necessary but it's faster)
watch ip -6 address show eno1

...and wait for it. It should occur till (appproximately) 10th generated temporary address.

Actual results:

inet6 2a00:aaaa:bbbb:cccc:54c1:62cb:e0f0:1e22/64 scope global temporary deprecated dynamic
valid_lft 86061sec preferred_lft 0sec
inet6 2a00:aaaa:bbbb:cccc:4876:8545:93b8:aecf/64 scope global temporary deprecated dynamic
valid_lft 86061sec preferred_lft 0sec
inet6 2a00:aaaa:bbbb:cccc:c181:fe8e:63d9:5a82/64 scope global temporary deprecated dynamic
valid_lft 86061sec preferred_lft 0sec
inet6 2a00:aaaa:bbbb:cccc:70d0:7f99:5c78:413f/64 scope global temporary deprecated dynamic
valid_lft 86061sec preferred_lft 0sec
inet6 2a00:aaaa:bbbb:cccc:1493:8c65:811d:1f8d/64 scope global mngtmpaddr noprefixroute dynamic
valid_lft 86061sec preferred_lft 14061sec
inet6 fe80::d928:e3fa:a19d:420c/64 scope link
valid_lft forever preferred_lft forever


Expected results:

The latest generated temporary address should always have "preferred_lft" > 0.


Additional info:

Comment 1 Justin M. Forbes 2017-04-11 14:50:29 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 25 kernel bugs.

Fedora 25 has now been rebased to 4.10.9-200.fc25.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26.

If you experience different issues, please open a new bug report for those.

Comment 2 Antonin 2017-04-15 10:34:19 UTC
The problem is still present.
I did test on my 2 PCs with Fedora OS and the result was the same:

uname -a
Linux nuc.home 4.10.9-200.fc25.x86_64 #1 SMP Mon Apr 10 14:48:16 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

sysctl -w net.ipv6.conf.eno1.use_tempaddr=2
sysctl -w net.ipv6.conf.eno1.temp_prefered_lft=1200

...after a few minutes:

ip address show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether c0:3f:d7:39:5f:a9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.109/24 brd 192.168.0.255 scope global dynamic eno1
       valid_lft 41789sec preferred_lft 41789sec
    inet6 2a00:aaaa:bbbb:cccc:10ef:41d2:8e7c:ea4d/64 scope global temporary deprecated dynamic 
       valid_lft 86148sec preferred_lft 0sec  <-- NOTICE THIS !!!
    inet6 2a00:aaaa:bbbb:cccc:1354:8d73:642e:2a96/64 scope global mngtmpaddr noprefixroute dynamic 
       valid_lft 86148sec preferred_lft 14148sec
    inet6 fe80::d928:e3fa:a19d:420c/64 scope link 
       valid_lft forever preferred_lft forever


After counter of lifetime for current temporary address gets to 0, no new temporary address is created.

Comment 3 Antonin 2017-08-07 08:44:31 UTC
Still remains in Fedora 26. (tested with kernel.x86_64 4.11.11-300.fc26)

Comment 4 Laura Abbott 2018-02-20 19:53:52 UTC
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  As kernel maintainers, we try to keep up with bugzilla but due the rate at which the upstream kernel project moves, bugs may be fixed without any indication to us. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.
 
Fedora 27 has now been rebased to 4.15.3-300.f27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you experience different issues, please open a new bug report for those.

Comment 5 Antonin 2018-02-25 14:03:01 UTC
Still remains in Fedora 27 (kernel 4.15.4-300.fc27.x86_64).

Comment 6 Justin M. Forbes 2018-07-23 15:20:29 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.

Fedora 27 has now been rebased to 4.17.7-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28.

If you experience different issues, please open a new bug report for those.

Comment 7 Justin M. Forbes 2018-08-29 15:13:46 UTC
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 5 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.


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