Bug 201488 - dummynet appears broken in 10.0-RELEASE and onwards (can't traffic shape on bridges)
Summary: dummynet appears broken in 10.0-RELEASE and onwards (can't traffic shape on b...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.0-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: Alexander V. Chernikov
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2015-07-12 03:56 UTC by James Rice
Modified: 2020-09-20 08:46 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Rice 2015-07-12 03:56:55 UTC
If I boot into a Live CD image from FreeBSD-9.3-RELEASE
and issue the following commands:

ifconfig bridge create
ifconfig bridge0 addm igb0 addm igb1 up
ifconfig igb0 up
ifconfig igb1 up
kldload dummynet
sysctl -w net.link.bridge.ipfw=1
ipfw -q 10 add pipe 100 ip from any to any
ipfw -q pipe 100 config bw 1Mb/s delay 100ms


I end up with a traffic shaped network (bandwidth is limited and delay is inserted) as expected between igb0 and igb1.


Following those exact same commands but with FreeBSD-10.0-RELEASE, FreeBSD-10.1-RELEASE, or FreeBSD-11.0-CURRENT, all the commands are accepted without any errors or warnings, however there is no bandwidth limiting and no delay inserted when passing traffic across the bridge.


It appears that dummynet is broken, at least for bridges, since at least 10.0-RELEASE.

Could this be fixed?


Thanks
James




Images used were:
ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/9.3/FreeBSD-9.3-RELEASE-amd64-mini-memstick.img
ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/10.0/FreeBSD-10.0-RELEASE-amd64-memstick.img
ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/10.1/FreeBSD-10.1-RELEASE-amd64-mini-memstick.img
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-amd64-20150630-r284969-mini-memstick.img
Comment 1 Hiren Panchasara freebsd_committer 2015-07-22 20:19:58 UTC
I ran into the same thing. I believe there is a problem in the order in which ipfw and dummynet modules are loaded.
Try kldunload dummynet ; kldunload ipfw ; kldload ipfw ; kldload dummynet

And then create rules and see if that works. (It does for me.)

Look at sysctl net.inet.ip.dummynet to see if dummynet is seeing packets go through.
Comment 2 Hiren Panchasara freebsd_committer 2015-07-22 22:58:06 UTC
+ freebsd-net 
and 
https://lists.freebsd.org/pipermail/freebsd-ipfw/2015-July/005892.html where I ran into a similar issue.
Comment 3 Mark C 2015-09-10 10:29:32 UTC
I have the same problem (FreeBSD 10.2).  

I've tried Hiren Panchasara's suggestion in Comment 1, but that doesn't fix the problem.

Note that traffic to and from either of the adapters that form part of the bridge DOES go via the pipe.  It's just traffic that gets bridged that doesn't go through the pipe.
Comment 4 Mark C 2015-09-23 09:28:29 UTC
After a lot of recompiling, it looks like the bug crept in with r240099 (committed by 'melifaro').
Comment 5 Tom Jones freebsd_committer 2020-09-19 14:46:24 UTC
Hiren's case of configuring any to any and pinging doesn't seem to still be a problem. I cannot reproduce here based on the steps in his email.

I don't see in your configuration anything that depends on bridge, i.e. you are restricting on the bridge interface. Due to the age of this report and I am going to close this issue.

If it still holds please reopen or create a new bug with specifics and tag me and I will investigate.
Comment 6 Mark C 2020-09-20 08:46:28 UTC
Hi Tom,

I still had this issue at the in January 2020, using the setup specified by James Rice in the bug description.

The issue is that the bridged traffic does not seem to get sent through the pipe, despite the firewall rule.

I tried with 10, 11, and 12 releases - I don't remember the exact versions - but I could only get James's configuration working with FBSD 9 releases.

I don't currently have access to the system that I used to test this, but I could organise to test any configurations that you have in mind, and send other debug information, a few weeks from now when I will hopefully have access the hardware again.