RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 586109 - traceroute don't like -l flowlabel, -t priority and -g nexthop option - rebase to 2.0.14
Summary: traceroute don't like -l flowlabel, -t priority and -g nexthop option - rebas...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: traceroute
Version: 6.0
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Jiri Skala
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks: 588669
TreeView+ depends on / blocked
 
Reported: 2010-04-26 20:03 UTC by Peter Bieringer
Modified: 2014-11-09 22:32 UTC (History)
7 users (show)

Fixed In Version: traceroute-2.0.14-1
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Release notes traceroute-2.0.14: This release fixes above all usage of flowlabel, priority and nexthop options. There is couple of other changes: * checks if the first hop is not null * fills unresolved IP address by its numeric interpretation * man pages improvements
Clone Of: 583985
Environment:
Last Closed: 2010-07-02 20:54:15 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Peter Bieringer 2010-04-26 20:03:19 UTC
Final RHEL6 should be also upgraded to traceroute-2.0.14 or at least to patched 2.0.13, because of:

http://www.redhat.com/rhel/beta/
Next generation networking: comprehensive IPv6 support

# rpm -q traceroute
traceroute-2.0.12-3.1.el6.i686

# LC_ALL=C traceroute -l 1 ::1
traceroute to ::1 (::1), 30 hops max, 80 byte packets
setsockopt IPV6_FLOWLABEL_MGR: Operation not permitted

# LC_ALL=C traceroute -t 4 ::1 
traceroute to ::1 (::1), 30 hops max, 80 byte packets
connect: Invalid argument

# LC_ALL=C traceroute -g ::1 ::1 
traceroute to ::1 (::1), 30 hops max, 104 byte packets
setsockopt IPV6_RTHDR: Invalid argument

+++ This bug was initially created as a clone of Bug #583985 +++

Description of problem:
traceroute don't like -l flowlabel option, looks like it can't set flowlabel during setsockopt

Version-Release number of selected component (if applicable):
traceroute-2.0.12-3.fc12.i686
kernel: 2.6.32.9-70.fc12.i686

How reproducible:
Always

Steps to Reproduce:
# LC_ALL=C traceroute -l 1 ::1
traceroute to ::1 (::1), 30 hops max, 80 byte packets
setsockopt IPV6_FLOWLABEL_MGR: Operation not permitted


Works without specifying flowlabel option:

# LC_ALL=C traceroute  ::1
traceroute to ::1 (::1), 30 hops max, 80 byte packets
 1  localhost (::1)  0.043 ms  0.020 ms  0.017 ms

--- Additional comment from dmitry on 2010-04-20 09:47:03 EDT ---

Well,

It seesm you are the first person who try this.

The code for flowlabels support was derived from some BSD's implementation, without actual checking due to missing good environment for such a check.

Could you help with this?

First of all, the issue might be I set flow_label "twice" -- in sin6_flowinfo field of the sin6 address, and then by setsockopt. Maybe it is an extra thing?..

--- Additional comment from pb on 2010-04-20 09:57:13 EDT ---

Yes, I'm currently playing around using tc for IPv6 for creating some examples for my howto.

As a short test setup, use tc to setup a flow label filter:

# tc qdisc add dev eth1 root handle 1: cbq avpkt 1000 bandwidth 1000Mbit
# tc class add dev eth1 parent 1: classid 1:1 cbq rate 1Mbit allot 1500 bounded
# tc filter add dev eth1 parent 1: protocol ipv6 u32 match ip6 flowlabel 1 0x3ffff flowid 1:1

and check with 
# tc -s filter show dev eth1

whether package matches filter (when option is proper working)

BTW: related problem is in ping6: https://bugzilla.redhat.com/show_bug.cgi?id=583976

--- Additional comment from dmitry on 2010-04-20 11:07:35 EDT ---

I've found the issue.

The problem is after the closing of IPv6 socket, the correspond flowlabel does not disappear. When we try to set the same flowlabel value the next time, it returns EPERM due to IPV6_FL_S_EXCL flag is set.

For example, try to do ICMP traceroute with yet unused flowlabel:

traceroute -6 -n -l 1111 something

and then repeat the same command. The first call is successful, the second is failed. AFter the 60 second (default expire time) the flow is reset, and you can try again...

With the defaukt traceroute method (UDP), we use separate sockets for each probe, hence the first proble of the first invokation is successfull, all other will be failed. Try fe.:

traceroute -6 -n -q1 -m1 -l 1111 something


Either we should drop IPV6_FL_S_EXCL flag (is it correct idea?), or try to play with flr_linger and flr_expires fields of the flowlabel struct used.

Additionally, it seems that setting of sin6_flowinfo is unuseful thing anyway...

--- Additional comment from dmitry on 2010-04-20 11:24:39 EDT ---

Created an attachment (id=407845)
traceroute-2.0.13-flowlabel.patch

The patch which fixes the issue.

IPV6_FL_S_EXCL changed to IPV6_FL_S_USER

Now the same user can use the same flowlabel any time. After the 6 second expiration (a kernel default) another users can "catch" this flow value etc...

Perhaps it would be more useful to change to IPV6_FL_S_ANY, but I'm not sure for now whether it is secure enough or not...

--- Additional comment from dmitry on 2010-04-21 10:14:43 EDT ---

The final decision is use IPV6_FL_S_ANY. If does not spoil anything.

Besides the flow labels, could you test some addtional IPv6-specific things? I mean `-g' traceroute option for example...

--- Additional comment from pb on 2010-04-22 01:29:25 EDT ---

Applied patch to traceroute 2.0.13 and rebuilt RPM on F12, option now works, but result is imho very buggy:

Flow label (decimal, using -l): tcpdump IPv6 header (first 64 bits)

0:    (0x0000): 0x0000:  6000 0000 0028 1110
1:    (0x0001): 0x0000:  6100 0000 0028 1110
2:    (0x0002): 0x0000:  6200 0000 0028 1110
15:   (0x000f): 0x0000:  6f00 0000 0028 1110
16:   (0x0010): 0x0000:  6000 0000 0028 1110
31:   (0x001f): 0x0000:  6f00 0000 0028 1110
32:   (0x0020): 0x0000:  6000 0000 0028 1110
127   (0x007f): 0x0000:  6f00 0000 0028 1110
4095  (0x0fff): connect: Invalid argument
16383 (0x3fff): connect: Invalid argument
16384 (0x4000): 0x0000:  6040 0000 0028 1110
65535 (0xffff): connect: Invalid argument
12345 (0x3039): 0x0000:  6930 0000 0028 1110


=> flow label is not stored in IPv6 header as expected, looks like is stored in completly wrong manner according to latest definition of IPv6 header.

From left:
Bit 0-3: Protocol (0x6) => ok
Bit 4-11: Traffic Class => buggy, part of flow level found, where only Traffic Class is expected (0x00)
Bit 12-31: Flow label => buggy, only part of flow level found

The "connect: Invalid argument" is also very strange

Is this a library, traceroute or a kernel bug??

Kernel is: 2.6.32.9-70.fc12.i686

--- Additional comment from pb on 2010-04-22 01:34:15 EDT ---

BTW: -g nexthop is also not working:

# LC_ALL=C traceroute -q 1 -g 2001:x:x:65::1 2001:x:x:66:5054:ff:fexx:x
traceroute to ipv6-client-b (2001:x:x:66:5054:ff:fexx:xxxx), 30 hops max, 104 byte packets
setsockopt IPV6_RTHDR: Invalid argument



--- Additional comment from pb on 2010-04-22 02:07:42 EDT ---

BTW2: -t TRAFFICCLASS is also not working:

# LC_ALL=C traceroute  -t 4  -q 1 www.ipv6.bieringer.de
traceroute to www.ipv6.bieringer.de (2001:a60:9002:1::186:6), 30 hops max, 80 byte packets
connect: Invalid argument

For IPv4 it is working:

# traceroute  -t 4  -q 1 www.bieringer.de
traceroute to www.bieringer.de (212.18.21.186), 30 hops max, 60 byte packets
 1  xxx
 2  xxx
 3  xxx
 4  xxx
 5  www.bieringer.de (212.18.21.186)  53.314 ms

--- Additional comment from dmitry on 2010-04-22 08:48:45 EDT ---

For comment #6:

I never touch any low-level headers, all the work is done by the kernel. I just perform socket(2), setsockopt(2) etc. calls with the appropriate arguments.

BTW, I cannot quite understand what is wrong exactly in your example. Could you provide the cmdline for traceroute and tcpdump, to make me a possibility to reproduce your case?


For comment #7:

Yep, `-g' currently does not work fot IPv6, because it use "route header type 0", but recently IETF and Linux kernel deny it (see RFC 5095).

I've already sent an e-mail to the traceroute-devel list on SourceForge -- Did you receive it? I've proposed to switch from "type 0" header to "type 2" (designed for Mobile IPv6), this way `-g' might work.

--- Additional comment from dmitry on 2010-04-22 10:08:46 EDT ---

Created an attachment (id=408330)
patch to fix flowlabel and tclass support

For comment #8:

Yep, it was a broken code. Thaks for the testings.

The final patch attached. It seems that now flow labels and tclass should work properly.

--- Additional comment from pb on 2010-04-22 13:20:48 EDT ---

Ok, flowlabel is now working correct and related tc filter matches, the traffic class (priority) also proper, but now "tc" has a bug if using "priority" option.

--- Additional comment from dmitry on 2010-04-22 13:26:09 EDT ---

> but now "tc" has a bug if using "priority" option.  

Hmmm... Can I help here?

--- Additional comment from pb on 2010-04-22 13:34:10 EDT ---

Filed a bug now for "tc": https://bugzilla.redhat.com/show_bug.cgi?id=584913

--- Additional comment from pb on 2010-04-24 06:29:12 EDT ---

Regarding https://bugzilla.redhat.com/show_bug.cgi?id=583985#c7, "-g nexthop" is now working well, tcpdump shows:

10:23:39.490351 IP6 2001:xxxx:xxxx:65:5054:ff:fexx:xxxx > 2001:xxxx:xxxx:65::1: srcrt (len=2, type=2, segleft=1, [0]2001:xxxx:xxxx:66:5054:ff:fexx:xxxx) ICMP6, echo request, seq 30, length 40

But regardless the settings on the router (routing eth1 <-> eth2) or using UDP instead of TCP and having source routing activated:

# sysctl -a |grep ipv6 | grep source
net.ipv6.conf.all.accept_source_route = 1
net.ipv6.conf.default.accept_source_route = 1
net.ipv6.conf.lo.accept_source_route = 1
net.ipv6.conf.eth0.accept_source_route = 1
net.ipv6.conf.eth1.accept_source_route = 1
net.ipv6.conf.eth2.accept_source_route = 1

the router neither respond to the packet back to client nor forward the packet et all. Can one confirm this issue, which is looking to me as a kernel problem.

Setup:

clientA -> router -> clientB

-g xxx the router's address was used (traceroute works without using this option)

Comment 2 RHEL Program Management 2010-04-26 21:27:03 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 3 Dmitry Butskoy 2010-04-27 12:53:45 UTC
New traceroute-2.0.14 is released upstream and submitted as an update for Fedora.

Comment 6 Jiri Skala 2010-04-28 10:53:29 UTC
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

New Contents:
Release notes traceroute-2.0.14:

This release fixes above all usage of flowlabel, priority and nexthop options.

There is couple of other changes:
* checks if the first hop is not null
* fills unresolved IP address by its numeric interpretation
* man pages improvements

Comment 10 releng-rhel@redhat.com 2010-07-02 20:54:15 UTC
Red Hat Enterprise Linux Beta 2 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.


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