Bug 2209701

Summary: "ip -6 route" command cuts ip address
Product: [Fedora] Fedora Reporter: lars.koeppel
Component: iprouteAssignee: Andrea Claudi <aclaudi>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 38CC: aclaudi, frank, psutter, rvokal, vbenes
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: iproute-6.4.0-1.fc38 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-09-17 01:26:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description lars.koeppel 2023-05-24 14:59:28 UTC
When using tailscale, it creats an interface with an ip address with a prefixlen of 128.

If i run "ip -6 route" it will cut the ip address after 31 characters. So the output looks like "aaaa:bbbb:cccc:dddd:eeee:ffff:g" but the output is expected to look like "aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh".

In Ubuntu and Arch the same command results in the correct output. Also the command "ip -6 addr" results in the correct output on all distros.

Reproducible: Always

Steps to Reproduce:
1. run Tailscale with ipv6
2. run command "ip -6 route"
Actual Results:  
aaaa:bbbb:cccc:dddd:eeee:ffff:g dev tailscale0 proto kernel metric 256 pref medium

Expected Results:  
aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh dev tailscale0 proto kernel metric 256 pref medium

Comment 1 lars.koeppel 2023-07-17 07:32:11 UTC
Since opening this bug report, i found from an other bug report(https://github.com/shemminger/iproute2/commit/890c599ec2e8905e7b8a433be3646d5d34901810), that the problem is connected to the glibc library.

They found a solution on how to fix this problem. Maybe you can have a look at it.

Comment 2 Frank Lichtenheld 2023-08-25 13:41:20 UTC
I ran into this problem today. I can confirm that it is fixed in iproute 6.4.0 in Fedora 39. Can we get iproute 6.4.0 in Fedora 38? Or is that too intrusive?

Comment 3 Andrea Claudi 2023-09-14 14:17:32 UTC
*** Bug 2238949 has been marked as a duplicate of this bug. ***

Comment 4 Fedora Update System 2023-09-14 20:15:17 UTC
FEDORA-2023-e549e258d8 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-e549e258d8

Comment 5 Fedora Update System 2023-09-15 01:06:34 UTC
FEDORA-2023-e549e258d8 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-e549e258d8`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-e549e258d8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 6 Vladimir Benes 2023-09-15 10:51:02 UTC
It works well for us in NetworkManager testing. The affected test case is passing now. 

  Scenario: nmcli - ipv6 - routes - set route with src
    * Prepare simulated test "testX6" device ... passed in 1.444s
    * Add "ethernet" connection named "con_ipv6" for device "testX6" with options ... passed in 0.040s
      """
      autoconnect no
      ipv6.method manual
      ipv6.addresses 2000::2/126
      ipv6.route-metric 256
      ipv6.routes '2806:aabb:abba:abab:baba:bbaa:baab:bbbb/128 src=2000::2'
      """
    * Bring "up" connection "con_ipv6" ... passed in 1.986s
    Then "2806:aabb:abba:abab:baba:bbaa:baab:bbbb dev testX6 proto static src 2000::2 metric 256" is visible with command "ip -6 route" in "5" seconds ... passed in 0.011s
    And "2000::\/126 dev testX6\s+proto kernel\s+metric 256" is visible with command "ip -6 route" ... passed in 0.009s
NetworkManager process id after: 138243 (now 138243)

Comment 7 Fedora Update System 2023-09-17 01:26:30 UTC
FEDORA-2023-e549e258d8 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.