Bug 823316

Summary:	unable to simulate drops with tc / netem
Product:	[Fedora] Fedora	Reporter:	Sebastiaan Jansen <iam.sebastiaan.jansen>
Component:	iproute	Assignee:	Petr Šabata <psabata>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	17	CC:	bill, joe, jpopelka, pborelli, psabata, rvokal, twoerner
Target Milestone:	---	Keywords:	Regression
Target Release:	---
Hardware:	i686
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-06-20 14:05:35 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Sebastiaan Jansen 2012-05-20 21:21:40 UTC

Description of problem:
I did an reinstall of system from fedora16 > fedora17-beta2 (fully updated) to test if the newly added 'correlated loss Generator' scenario's in netem are working, after the fedora upgrade I get the message 'RTNETLINK answers: No such file or directory' when I apply:

$ tc qdisc add dev p2p1 root netem delay 100ms
OR
$ tc qdisc change dev p2p1 root handle 1: prio
OR (the changed loss commands since iproute2-3.x.x)
$ tc qdisc add dev p2p1 root netem loss random 10%

currently the interface is set default:
$ tc qdisc show dev p2p1
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Ofcourse I'm root, and tried to switchoff selinux.
In fedora16 the (unchanged) commands worked.

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

iproute-3.3.0-2.fc17.i686

How reproducible:

Steps to Reproduce:
1. tc qdisc add dev p2p1 root netem loss random 10%
2. tc qdisc add dev p2p1 root netem delay 100ms
3.
  
Actual results:
RTNETLINK answers: No such file or directory

Expected results:
applied netem setting

Additional info:

Comment 1 Joseph D. Wagner 2012-06-13 08:47:13 UTC

Please add keyword: Regression

This appears to be affecting all traffic control.  This exact script worked on my Fedora 16 machine, but it no longer works on the same machine in Fedora 17.  It now returns the same error message on the first line:

RTNETLINK answers: No such file or directory

## UPSTREAM TRAFFIC SHAPPING
/sbin/tc qdisc add dev p6p1 root handle 1: htb default 10
/sbin/tc class add dev p6p1 parent 1: classid 1:1 htb rate 2mbit burst 2k
/sbin/tc class add dev p6p1 parent 1:1 classid 1:10 htb rate 2mbit burst 2k
/sbin/tc class add dev p6p1 parent 1:1 classid 1:20 htb rate 1536kbit burst 2k
/sbin/tc qdisc add dev p6p1 parent 1:10 handle 10: prio
/sbin/tc qdisc add dev p6p1 parent 1:20 handle 20: sfq perturb 30
# ICMP
/sbin/tc filter add dev p6p1 parent 1: protocol ip prio 1 u32 match ip protocol 1 0xff flowid 1:10
# Interactive Ports
/sbin/tc filter add dev p6p1 parent 1: protocol ip prio 2 u32 match ip dport 0 0xfc00 flowid 1:10
# Bulk Ports (Catch-All)
/sbin/tc filter add dev p6p1 parent 1: protocol ip prio 3 u32 match ip dport 0 0x0000 flowid 1:20

Comment 2 paolo borelli 2012-06-20 09:35:27 UTC

I have a similar problem... the "RTNETLINK answers: No such file or directory" message is surely not very helpful :)

That said I "fixed" it by installing kernel-modules-extras

Comment 3 Bill Shirley 2012-06-20 13:37:28 UTC

Thank you!!

This fixed it for me also.  I was having a problem with Shorewall's TC_ENABLED=Internal in shorewall.conf.

Comment 4 Petr Šabata 2012-06-20 14:05:35 UTC

(In reply to comment #2)
> I have a similar problem... the "RTNETLINK answers: No such file or
> directory" message is surely not very helpful :)

That's a kernel response; there's not much to do about it.

Apparently the module was moved to the extras package; this happens sometimes for various reasons.  It's good to know how to fix the issue, thanks for sharing.

Comment 5 paolo borelli 2012-06-20 15:10:08 UTC

can maybe make iproute depend on that? or maybe the issue should be brought to the attention of the kernel packagers

Comment 6 Petr Šabata 2012-06-21 08:02:18 UTC

It's optional functionality, hence the 'extras' in the name.  Hard-requiring it (there's no other way in RPM) is a no-go.

What goes in the extras package is decided by the kernel people, indeed.  If you believe this is a module that should be part of every Fedora installation, file a bug with kernel.