[hardy] running wondershaper gives 'What is "flowid"? Illegal "police"'

Bug #194623 reported by Michael R. Head
46
Affects Status Importance Assigned to Milestone
PLD Linux
Invalid
Undecided
Unassigned
Nominated for Ac by Łukasz Jernaś
iproute (Debian)
Fix Released
Unknown
iproute (Ubuntu)
Fix Released
Undecided
Unassigned
Hardy
Fix Released
Undecided
Unassigned
shorewall (Ubuntu)
Invalid
Undecided
Unassigned
Hardy
Invalid
Undecided
Unassigned
wondershaper (Ubuntu)
Fix Released
Undecided
Unassigned
Hardy
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: wondershaper

Latest checked version: 1.1a-4.1

Just upgrade my router from dapper to hardy. I'm seeing a problem with the wondershaper package. I've been running it like so from /etc/network/interface (as a post-up operation):

wondershaper eth3 4500 333

Doing ifup now gives:
$ sudo ifup eth3
... snip dhcp ...
What is "flowid"?
Illegal "police"
Failed to bring up eth3.

Now, when I run it, I get error messages:
burner@firewall:~$ sudo wondershaper eth3 4500 333
What is "flowid"?
Illegal "police"

And it doesn't seem to be limiting the transfer rates.

TEST CASE:
 * install the wondershapper package.
 * run the command:
    sudo /usr/sbin/wondershaper eth0 48 48

Output with -2ubuntu1:
  What is "flowid"?
  Illegal "police"

Output with 2ubuntu2: nothing.

Revision history for this message
James Blackwell (jblack) wrote :

Still valid as of 18 March, 2008

Changed in wondershaper:
status: New → Confirmed
Revision history for this message
tech0007 (tech0007) wrote :

got the same when i ran wondershaper in my box.

tech0007@myubuntu:~$ sudo /usr/sbin/wondershaper eth0 48 48
What is "flowid"?
Illegal "police"

What does it mean? flowid? illegal police?

Revision history for this message
Michael R. Head (burner) wrote :

A Gentoo bug on another package suggests that flowid should be removed from the lines that are using it: http://bugs.gentoo.org/show_bug.cgi?id=213624

Revision history for this message
Michael R. Head (burner) wrote :
Revision history for this message
Michael R. Head (burner) wrote :

So I guess the change in iproute (or the kernel?) has caused the wondershaper program to fail.

Revision history for this message
Michael R. Head (burner) wrote :

BTW: it's this line (at the end of /usr/sbin/wondershaper) that's causing the trouble:
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

And, indeed, removing "flowid :1" from that line causes wondershaper to complete successfully. I haven't been able to test whether it still limits bandwidth properly and maintains low latency under high transfer rates.

Revision history for this message
tech0007 (tech0007) wrote :

Any updates?

Revision history for this message
tech0007 (tech0007) wrote :

Is there an alternative to using wondershaper?

Revision history for this message
way-out (mmc48) wrote :

so here maybe the decision http://<email address hidden>/msg27754.html how can we use it? Ubuntu Hardy

Revision history for this message
Michael R. Head (burner) wrote :

Ilike I said, you just need to take "flowid :1" off of the last line in /usr/sbin/wondershaper and wondershaper will run.

Revision history for this message
way-out (mmc48) wrote :

tried commenting out last 2 lines => wondershaper worked but lost it's functionality.
Now commented only flowid :1 so they look like:
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
  0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop #flowid :1

seems like working now! thank you!

Revision history for this message
Rudd-O (rudd-o) wrote :

Guys, the latest iproute2 package (which I compiled from source by hand, by the way) fixes this issue. However, the wondershaper burst sizes need to grow (in my case, I had to set burst to 15k in the ingress policer rule) otherwise the shaping goes bonkers.

Please upgrade to the latest release candidate for iproute2 ASAP.

Revision history for this message
tech0007 (tech0007) wrote : Re: [Bug 194623] Re: [hardy] running wondershaper gives 'What is "flowid"? Illegal "police"'
  • unnamed Edit (750 bytes, text/html; charset=utf-8)
  • unnamed Edit (189 bytes, application/pgp-signature; name=signature.asc)

Is iproute2 available in the repo? Is it enough if I do apt-get
update/upgrade?

On Fri, 2008-04-04 at 11:10 +0000, Rudd-O wrote:

> Guys, the latest iproute2 package (which I compiled from source by hand,
> by the way) fixes this issue. However, the wondershaper burst sizes
> need to grow (in my case, I had to set burst to 15k in the ingress
> policer rule) otherwise the shaping goes bonkers.
>
> Please upgrade to the latest release candidate for iproute2 ASAP.
>

Revision history for this message
Jan Groenewald (jan-aims) wrote :

0 root@kontiki:~/bin#cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"
0 root@kontiki:~/bin#modprobe sch_ingress
0 root@kontiki:~/bin#modprobe cls_fw
0 root@kontiki:~/bin#tc qdisc del dev eth1 ingress
0 root@kontiki:~/bin#tc qdisc add dev eth1 handle ffff: ingress
0 root@kontiki:~/bin# tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match ip dst 192.168.172.0/16 police rate 64kbit burst 15k drop flowid :1
What is "flowid"?
Illegal "police"
0 root@kontiki:~/bin# tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match ip dst 192.168.172.0/16 police rate 64kbit burst 15k drop
0 root@kontiki:~/bin#tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match ip dst 172.18.172.0/16 police rate 128kbit burst 20k drop
0 root@kontiki:~/bin#tc -s -d qdisc
qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 771955 bytes 15652 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc pfifo_fast 0: dev eth1 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 2036007917 bytes 6082709 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
 Sent 1807867 bytes 3563 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0

Above nevers shows dropped > 0.

References:
1 http://<email address hidden>/msg27754.html
2 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=45853
3 http://bugs.gentoo.org/show_bug.cgi?id=213624
4 http://www.shorewall.com.au/3.4/shorewall-3.4.7/errata/patches/Shorewall/patch-3.4.7-2.diff

As Hardy stable release is imminent, should it not revert, patch, or upgrade this week?
A hardy LTS server should be able to use tc, wonderhsaper, especially as many people
rely on very basic ingress limiting for non port-80 traffic (which can be handled by squid buckets).

Revision history for this message
Jan Groenewald (jan-aims) wrote :

Above post refers to iproute version:

0 jan@kontiki:~$COLUMNS=200 dpkg -l iproute
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-============================================-============================================-========================================================================================================
ii iproute 20071016-1ubuntu1 Professional tools to control the networking in Linux kernels

Revision history for this message
Jan Groenewald (jan-aims) wrote :

Today's udpate is a new iproute, but the problem persists. Even with
the limit set to 1kbit, I can see with iftop much more traffic, but no
packets are dropped.

0 root@kontiki:~/bin#COLUMNS=200 dpkg -l iproute
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-============================================-============================================-========================================================================================================
ii iproute 20071016-2ubuntu1 Professional tools to control the networking in Linux kernels

Revision history for this message
Fernando Torres (fernando-torres) wrote :

Hi

In the web page (http://lartc.org/wondershaper) of wondershaper refers to use an especific version of iproute2 if the last 2 lines of script don't work. The link for this version is http://lartc.org/wondershaper/iproute2-2.4.7-now-ss010824.tar.gz

Revision history for this message
Ruben RiCe (macareno) wrote :

Confirmed. Still valid as of 21 April, 2008.

Revision history for this message
Diego Gaustein (gregorovius) wrote :

Happens to me too on a freshly installed Hardy final.

Revision history for this message
Tomas 'tt' Krag (tt) wrote :

Just to add, that this bug also prevents shorewall from running properly if it is started with traffic control enabled, i.e. if /etc/shorewall/shorewall.conf has the line

TC_ENABLED=Internal

which i believe is default for shorewall

Revision history for this message
DurvalMenezes (durval) wrote :

Bug still present in a Hardy install with all updates applied as of 2008/05/06 09:48am.
Commenting the "flowid :1" as stated above seems to work around the problem.

Revision history for this message
Savvas Radevic (medigeek) wrote :

Confirming:
$ apt-cache policy wondershaper
wondershaper:
  Installed: 1.1a-4.1
  Candidate: 1.1a-4.1
  Version table:
     1.1a-4.1 0
        500 http://nl.archive.ubuntu.com hardy/universe Packages

description: updated
Revision history for this message
schnollk (schnollk) wrote :

me, too

$ apt-cache policy wondershaper
wondershaper:
  Installed: 1.1a-4.1
  Candidate: 1.1a-4.1
  Version table:
 *** 1.1a-4.1 0
        500 http://de.archive.ubuntu.com hardy/universe Packages
        100 /var/lib/dpkg/status

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04"

Revision history for this message
schnollk (schnollk) wrote :

added "affects also" for shorewall as Jan Groenewald and Tomas 'tt' Krag suggested.

Revision history for this message
schnollk (schnollk) wrote :

commenting out flowid :1 in the last line seams to do the job here as well. Not only does wondershaper run through it also seams to traffic shape on a first glimpse.

Thanks, Michael R. Head and doff for sharing the workaround.

Revision history for this message
LEVIS Cyril (atlas95) wrote :

Is this program working currently on hardy? I don't understand those message too :
What is "flowid"?
Illegal "police"

Revision history for this message
Adolfo R. Brandes (arbrandes) wrote :

This is a bug in iproute, not in wondershaper. Debian has already fixed the problem:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458539

I can confirm that iproute_20071016-3 fixes it. Here an i386 link, for conveniency:

http://mirror.aarnet.edu.au/debian/pool/main/i/iproute/iproute_20071016-3_i386.deb

Changed in iproute:
status: Unknown → Fix Released
Revision history for this message
Fernando Miguel (fernandomiguel) wrote :

this no longer shows up on Interpid
wondershaper v 1.1a-4.1

Changed in wondershaper:
status: Confirmed → Fix Released
Revision history for this message
Fernando Miguel (fernandomiguel) wrote :

typo: it should be Intrepid... lol

iproute intrepid version: 200804174-1

Revision history for this message
Ivo Cavalcante (iscc) wrote :

Just to keep the bug 'alive' and put some 'pressure'... :-)
Easy, boys, just a joke, I know how things work.

Still valid, preventing Shorewall to start.

Revision history for this message
dchard (metro4-freemail) wrote :

Still valid on 2008-06-15

Replacing iproute2 with this http://mirror.aarnet.edu.au/debian/pool/main/i/iproute/iproute_20071016-3_i386.deb solved the problem, nothing has to be rewrite and the shaper functioning like it should.

Adolfo R. Brandes: thank you for the link.

Dchard

Matt LaPlante (cybrmatt)
Changed in iproute:
status: New → Confirmed
Revision history for this message
Brian Murray (brian-murray) wrote :

This is actually fixed in Intrepid so I am marking it as Fix Released. However, there is still and open Hardy task which is eligible for a Stable Release Update.

Changed in iproute:
status: Confirmed → Fix Released
Revision history for this message
Mathias Gug (mathiaz) wrote :

I've attached a debdiff that fixes the issue.

It's a patch taken from debian revision 20071016-3.

The change has also been applied to the upstream tree (http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=commit;h=ef1d6f97ec725e5e942f092ab4f5a4ceff17bb9c).

TEST CASE:
 * install the wondershapper package.
 * run the command:
    sudo /usr/sbin/wondershaper eth0 48 48

Output with -2ubuntu1:
  What is "flowid"?
  Illegal "police"

Output with 2ubuntu2: nothing.

description: updated
Revision history for this message
Johan Mulder (johan-launchpad) wrote :

It works indeed. Thanks :)

Revision history for this message
Martin Pitt (pitti) wrote :

Accepted into hardy-proposed, please test.

What about the shorewall and wondershaper tasks, in intrepid and hardy? Please close the irrelevant ones as "invalid" and triage the ones which are "New".

Changed in iproute:
status: New → Fix Committed
Revision history for this message
Steve Beattie (sbeattie) wrote :

I was able to reproduce the wondershaper behavior with iproute 20071016-2ubuntu1 from the hardy 8.04 release. I can confirm that the iproute package in hardy-proposed, 20071016-2ubuntu2, does fix the behavior when wondershaper is started. The rate limiting that wondershaper does is also set up more effectively with the updated iproute package; I did not notice any regressions with basic wondershaper usage and some test file transfers.

I was not able to reproduce the shorewall failing to start behavior. However, I'm marking both the wondershapr and shorewall tasks as invalid, as I believe the iproute update fixes them. If that's incorrect, please reopen by marking the tasks as New and provide more information to track down the specific issues within those packages. Thanks for helping to improve Ubuntu!

Changed in shorewall:
status: New → Invalid
Changed in wondershaper:
status: New → Invalid
Changed in shorewall:
status: New → Invalid
Revision history for this message
Martin Pitt (pitti) wrote :

Copied to hardy-updates.

Changed in iproute:
status: Fix Committed → Fix Released
Revision history for this message
Leonardo (rnalrd) wrote :

Anybody still have the same problem with updated package iproute_20071016-2ubuntu2 with Shorewall under Hardy Server?

Revision history for this message
Leonardo (rnalrd) wrote :

Sorry, please ignore it

Revision history for this message
Jan Groenewald (jan-aims) wrote :

I am running jaunty beta now and though there is now flowid error, I still get no packets dropped.

dino99 (9d9)
Changed in pld-linux:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.