[Bug #3032] IPFW3: memory leakage? objcache(xxx): Exhausted!

[Aaron LI]

On Wed, 2017-06-07 at 23:54 +0800, Aaron LI wrote:
> 
> I think it's easy to reproduce this issue with a VM (e.g., VirtialBox)
> installed the latest DFly release or master snapshot, configure about 256 or
> 512 MB RAM, enable IPFW3 (I used the basic and layer4 modules), and
> continuously download/upload some data.  Also keep monitoring the mbuf
> usages (netstat -m).
> 
> I will set up a VM to test this issue and report to you.

Hi Bill,


I've set up a VM with DFly 4.8.0-Release to test this issue, and find that the
issue is very likely caused by the *UDP traffic state check* for IPFW3.

A. VM & System
==============
Host OS: Debian Linux (testing) amd64
VM emulator: VirtualBox 5.1.10
VM memory: 256 MB RAM
Guest OS: DragonFly BSD 4.8.0-Release
Guest network: 192.168.1.236 (bridged)
Host network: 192.168.1.0/24

B. Results
==========
1. With basic IPFW3 rules: "check-state" and "allow tcp from me out via em0
keep-state",
   (1) downloading a lot of data from a remote host: OK (mbuf usages);
   (2) "scp" a lot of data to a remote host: OK (mbuf usages).

2. Use the full IPFW3 rules configured for my home DFly machine (attached
below), then monitor the mbuf usages, and I find the mbuf usages *keep
increasing* as the UDP traffic increases.  For example, after the VM running
for an afternoon:

---------------------------------------------------------
vbox# netstat -m
2652/10560 mbufs in use (current/max):
519/1536 mbuf clusters in use (current/max)
0/512 mbuf jumbo clusters in use (current/max)
	3116 mbufs and mbuf clusters allocated to data
	52 mbufs and mbuf clusters allocated to packet headers
2364 Kbytes allocated to network (28% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines

vbox# ipfw3 show | egrep -v '\s+0\s+0\s+'
00100  859  90620  check-state
00200    2     80  allow tcp from me out via em0 keep-state
00304   12   4088  deny from 0.0.0.0/8 in via em0
00305    3    984  deny from 169.254.0.0/16 in via em0
00310    6    504  allow icmp in via em0 keep-state
00332   17   1632  deny tcp established in via em0
00500  829  87621  allow tcp dst-port 22 in via em0 keep-state
00701 2176 211072  allow udp dst-port 21027 in via em0 keep-state
60000 1319 179663  deny in via em0
---------------------------------------------------------

NOTE:
* The UDP port 21027 is used by Syncthing (https://syncthing.net/) for
discovery broadcasts on IPv4 and multicasts on IPv6.  I'm running Syncthing on
3 other hosts within the LAN 192.168.1.0/24.
* The VM is just idle and runs nothing.

Wish the information help you reproduce and then solve this issue.


My full IPFW3 rules:
---------------------------------------------------------
00010  allow via lo0
00100  check-state
00200  allow tcp from me out via em0
keep-state
00201  allow udp from me out via em0 keep-state
00202  allow icmp
from me out via em0 keep-state
00301  deny from 172.16.0.0/12 in via em0
00303  
deny from 127.0.0.0/8 in via em0
00304  deny from 0.0.0.0/8 in via em0
00305  de
ny from 169.254.0.0/16 in via em0
00306  deny from 192.0.2.0/24 in via em0
00307
  deny from 204.152.64.0/23 in via em0
00308  deny from 224.0.0.0/3 in via em0
0
0310  allow icmp in via em0 keep-state
00315  deny tcp dst-port 113 in via em0
0
0320  deny tcp dst-port 137 in via em0
00321  deny tcp dst-port 138 in via em0
0
0322  deny tcp dst-port 139 in via em0
00323  deny tcp dst-port 81 in via em0
00
332  deny tcp established in via em0
00500  allow tcp dst-port 22 in via em0
keep-state
00500  allow tcp dst-port 8860 in via em0 keep-state
00510  allow tcp
dst-port 80 in via em0 keep-state
00512  allow tcp dst-port 8800 in via em0
keep-state
00513  allow tcp dst-port 8801 in via em0 keep-state
00700  allow tcp
dst-port 22000 in via em0 keep-state
00701  allow udp dst-port 21027 in via em0
keep-state
00800  allow dst-port 51413 in via em0 keep-state
00801  allow tcp
from 192.168.1.0/24 dst-port 9091 in via em0 keep-state
60000  deny in via em0
6
5535  deny
---------------------------------------------------------


Regards,
-- 
Aly
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20170608/be3e5b07/attachment-0007.bin>