Adding IPv6 address to vlan in UNKNOWN state results in routes that expire within 30 days.

[SaveTheRbtz]

We noticed that after adding IPv6 address to vlan route to local network is added with expiration time. If after `ip link set vlanXXX up` up we wait until vlan's link state becomes UP then route get added without expiration time.

We are using Ubuntu LTS 10.04: Ubuntu 2.6.32-32.62-server 2.6.32.38+drm33.16.

To reproduce one can use following test script:
$ cat test.sh
ip addr del 2a02::1.1.1.1/64 dev vlan764 || :
vconfig rem vlan764 || :
vconfig set_name_type VLAN_PLUS_VID_NO_PAD
vconfig add eth0 764
ip link set vlan764 up
#sleep 5
ip addr add 2a02::1.1.1.1/64 dev vlan764
sleep 2
ip -6 route show

$ sudo ./test.sh
2a02::/64 dev vlan764 proto kernel metric 256 expires 2591999sec mtu 8950 advmss 8890 hoplimit 4294967295
fe80::/64 dev eth0 proto kernel metric 256 mtu 8950 advmss 8890 hoplimit 4294967295
fe80::/64 dev vlan764 proto kernel metric 256 mtu 8950 advmss 8890 hoplimit 4294967295
default via fe80::226:bff:fe29:c40 dev vlan764 proto kernel metric 1024 expires 1799sec mtu 8950 advmss 8890 hoplimit 64

Notice `expires 2591999sec` in `2a02::/64 dev vlan764 ` route
Now uncomment `#sleep 5`

$ sudo ./test.sh
2a02::/64 dev vlan764 proto kernel metric 256 mtu 8950 advmss 8890 hoplimit 4294967295
fe80::/64 dev eth0 proto kernel metric 256 mtu 8950 advmss 8890 hoplimit 4294967295
fe80::/64 dev vlan764 proto kernel metric 256 mtu 8950 advmss 8890 hoplimit 4294967295
default via fe80::226:bff:fe29:c40 dev vlan764 proto kernel metric 1024 expires 0sec mtu 8950 advmss 8890 hoplimit 64

Now `expire` is gone.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 917643

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . If possible, please test the latest v3.2 kernel[1] (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed by the mainline kernel, please add the following tag 'kernel-fixed-upstream-KERNEL-VERSION'. For example, if kernel version 3.2-rc1 fixed the issue, the tag would be: 'kernel-fixed-upstream-v3.2-rc1'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'. If you believe this bug does not require upstream testing, please add the tag: 'kernel-upstream-testing-not-needed'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[SaveTheRbtz (savetherbtz)]

Tested on Ubuntu Oneiric's 3.0 - there is no such problem there.
I've also can test it on other backport kernels when i get to work.