On the trail of a dummynet/bridge/ipfw bug.

Wade Klaver wadeklaver at itiva.com
Wed Mar 12 18:00:02 UTC 2008


I have a bridge set up on a 7.0 box and am attempting to use it to limit
HTTP connections outgoing from a box behind it to 192Kbit/s for testing.
During this testing I ran into some problems.  At first, I found that
the number of simultaneous pipes was limited to 1024, allowing only 1024
192Kbit/s clients.  Additional clients were simply blocked.  I am using
a very simple firewall config:

  ipfw pipe 1 config bw 192Kbits/s mask all
  ipfw add 00051 skipto 99 ip from to
  ipfw add 00052 skipto 1000 ip from any to any
  ipfw add 00100 pipe 1 ip from 80 to any via bridge0
  ipfw add 00200 pipe 1 ip from any 25111 to any via bridge

Regardless of how many clients I threw at the box, I had the limit:

[root at ibm3550b ~]# ipfw pipe show | wc -l

We managed to track this down to a problem in the ipfw2 userland app.
The following patch to /usr/src/sbin/ipfw/ipfw2.c allowed this limit to
be surpassed.  It would appear that ipfw does not dynamically resize the
pipe array beyond the initial 1024 elements allocated.

# diff ipfw2.c ipfw2.c.orig 
<       int nalloc = 8192;      /* start somewhere... */
>       int nalloc = 1024;      /* start somewhere... */

However, this just revealed a bigger problem, potentially do to the
above patch, potentially due to something worse.  Now the bridge will
allow more connections, up to around 2300 where the bridge just dies.
and no more traffic passes.  It is worth noting that I can still connect
to the bridge itself if it has an IP assigned to it, but traffic through
the bridge ceases.  It is also remedied by a /etc/rc.d/netif restart.

Please let me know if there is any additional information I can provide.
In the kernel options below, HZ=2000 was just something I was trying.
The problem exhibits itself with HZ=1000 as well.
I posted this to -hackers and to -ipfw. Please direct me and future correspondence 
on this issue to the most appropriate list.  I just felt it was not
solid enough to go to -bugs yet.

IBM 3550
XEON 5345
4GB Memory
[root at ibm3550b /usr/src/sys]# uname -a
FreeBSD ibm3550b.itivalabs.net 7.0-STABLE FreeBSD 7.0-STABLE #13: Wed
Mar 12 03:26:08 PDT 2008
root at ibm3550b.itivalabs.net:/usr/obj/usr/src/sys/WADE  amd64

Bridge members:
bce0: <Broadcom NetXtreme II BCM5708 1000Base-T (B2)> mem
0xc8000000-0xc9ffffff irq 18 at device 0.0 on pci4
bce1: <Broadcom NetXtreme II BCM5708 1000Base-T (B2)> mem
0xce000000-0xcfffffff irq 16 at device 0.0 on pci6

Kernel options:
# Make an SMP-capable kernel by default
options         SMP        # Symmetric MultiProcessor Kernel
options         LIBALIAS
options         IPFIREWALL              #firewall
options         IPFIREWALL_VERBOSE      #enable logging to syslogd(8)
options         IPFIREWALL_VERBOSE_LIMIT=100    #limit verbosity
options         IPFIREWALL_DEFAULT_TO_ACCEPT    #allow everything by
options         IPFIREWALL_FORWARD      #packet destination changes
options         IPFIREWALL_NAT          #ipfw kernel nat support
options         IPDIVERT                #divert sockets
#options         IPFILTER                #ipfilter support
#options         IPFILTER_LOG            #ipfilter logging
#options         IPFILTER_LOOKUP         #ipfilter pools
#options         IPFILTER_DEFAULT_BLOCK  #block all packets by default
options         IPSTEALTH               #support for stealth forwarding
options         MBUF_STRESS_TEST
options         DUMMYNET
options         HZ=2000
options         EXT2FS


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080312/c5dc3e46/attachment.pgp

More information about the freebsd-hackers mailing list