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



## frozen (Apr 9, 2014)

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 -> 127.0.0.1 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
#     http://spamlinks.net/filter-bl.htm

all:\
        :uatraps:nixspam:

# University of Alberta greytrap hits.
# Addresses stay in it for 24 hours from time they misbehave.
uatraps:\
        :black:\
        :msg="Your address %A has sent mail to a ualberta.ca spamtrap\n\
        within the last 24 hours":\
        :method=http:\
        :file=www.openbsd.org/spamd/traplist.gz

# Nixspam recent sources list.
# Mirrored from http://www.heise.de/ix/nixspam
nixspam:\
        :black:\
        :msg="Your address %A is in the nixspam list\n\
        See http://www.heise.de/ix/nixspam/dnsbl_en/ for details":\
        :method=http:\
        :file=www.openbsd.org/spamd/nixspam.gz
```

Running `/usr/local/sbin/spamd-setup -b -d` produces this output:

```
[R] snip:~ # /usr/local/sbin/spamd-setup -b -d
Getting http://www.openbsd.org/spamd/traplist.gz
blacklist uatraps 61436 entries
Getting http://www.openbsd.org/spamd/nixspam.gz
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!

-frozen


----------



## Chris_H (Apr 11, 2014)

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

--Chris


----------



## frozen (Apr 12, 2014)

Thank you Chris.

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

-frozen

//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.


----------



## MonkeyLord (Jul 26, 2014)

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,
```


----------



## eri@ (Oct 18, 2014)

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


----------

