pfctl returns "Bad address." after running spamd-setup


New Member

Messages: 13

Hello Forum,
I'm running spamd-4.9.1_1 on FreeBSD 10.0-RELEASE #0 r260789.

These are the relevant pf.conf entries:
table <spamd> persist

rdr pass on $if proto tcp from <spamd> to $ip port 25 -> port 8025

set limit { states 10000, frags 5000, table-entries 250000 }

This is the content of /usr/local/etc/spamd/spamd.conf
 $OpenBSD: spamd.conf,v 1.3 2007/05/12 00:43:41 cnst Exp $
# spamd(8) configuration file, read by spamd-setup(8).
# See also spamd.conf(5).
# Configures lists for spamd(8).
# Strings follow getcap(3) convention escapes, other than you
# can have a bare colon (:) inside a quoted string and it
# will deal with it. See spamd-setup(8) for more details.
# "all" must be here, and defines the order in which lists are applied.
# Lists specified with the :white: capability apply to the previous
# list with a :black: capability.
# As of November 2004, a place to search for blacklists is


# University of Alberta greytrap hits.
# Addresses stay in it for 24 hours from time they misbehave.
        :msg="Your address %A has sent mail to a spamtrap\n\
        within the last 24 hours":\

# Nixspam recent sources list.
# Mirrored from
        :msg="Your address %A is in the nixspam list\n\
        See for details":\

Running /usr/local/sbin/spamd-setup -b -d produces this output:
[R] snip:~ # /usr/local/sbin/spamd-setup -b -d
blacklist uatraps 61436 entries
blacklist nixspam 39999 entries
[R] snip:~ # pfctl: Bad address.

I expected pfctl -t spamd -T show to return the addresses fed into the table by /usr/local/sbin/spamd-setup -b -d but instead the table seems empty.
[R] snip:~ # pfctl -t spamd -T show
No ALTQ support in kernel
ALTQ related functions disabled

Interestingly I've got a FreeBSD 9.2-RELEASE-p3 #0 machine running the same setup just fine.

I'm thankful for any input you may provide!




Reaction score: 211
Messages: 1,076

What happens if you restart the service (pf(4))? My guess is that pf(4) hasn't yet seen/found the spamd table.



New Member

Messages: 13

Thank you Chris.

I ran pfctl -F all -f /etc/pf.conf to clear and restart pf(), but the problem persists.


//UPDATE #1 16-04-2014: This issue became intermittent without any interaction. The last night and now, upon running the command manually, there is no error anymore. Maybe something with the way the list is formed was not right.


New Member

Messages: 1

This appears to be a problem inside the PF ioctl that sets the addresses, DIOCRSETADDRS. It seems to need a lot of free space in the array that is passed into the kernel in order to actually perform the table replace operation, otherwise it will fail with EFAULT, aka 'Bad Address'.

The intermittent nature of the problem is due to the varying size of the spam lists.

You can patch your local pfctl to give it a bigger buffer pretty easily, though. The change below ensures that there are at least as many empty slots in the array as there are addresses that are getting added. It appears to work for me, anyway...

--- /usr/src/sbin/pfctl_table.c.orig    2014-07-26 14:53:23.978341366 -0400
+++ /usr/src/sbin/pfctl_table.c    2014-07-26 14:52:51.053961802 -0400
@@ -233,6 +233,10 @@
         if (opts & PF_OPT_VERBOSE)
             flags |= PFR_FLAG_FEEDBACK;
         for (;;) {
+            /* the ioctl needs a BIG buffer, so give it one */
+            if (b.pfrb_msize < b.pfrb_size * 2)
+                pfr_buf_grow(&b, b.pfrb_msize * 2);
             int sz2 = b.pfrb_msize;

             RVTEST(pfr_set_addrs(&table, b.pfrb_caddr, b.pfrb_size,
Last edited by a moderator:


New Member

Messages: 1

This is not a pfctl issue rather than an ioctl issue. I will have to push soon a patch to fix it.