I'm having some trouble understanding the use of max-src-conn-rate. Any
help would be welcome.

I'been trying to use this option on port 25 on my mail server at home,
with a view to eventually trying to prevent at least some spam. The
behaviour hasn't been at all what I expected, and I obviously have
misunderstood something, so for now, I've got a test setup on my LAN as
follows:

Server machine ("data.scotts", 192.168.0.1) has an entry in pf.conf thus:

table persist
.....
block in log all
block out all
pass in log quick on dc0 from wesley.scotts to dc0 flags S/SA keep
state (max-src-conn-rate 1/30, overload )

(dc0 being the LAN interface, and wesley a test client) -- this is close
to the start of the rules to make sure it's operative. There's a later
pass rule anyway for known LAN clients; the logs show the rule above is
the one that's hit, as expected.

On the client, wesley.scotts (192.168.0.6), I'm using 'nc' in a loop to
create a continuous stream of connect requests at about 1 per second
(echo -n "$x.. " | nc -o data.scotts 1234
where x is a loop counter)

I'm doing a tail on the pf log output.

By my understanding, this should cause wesley to be put into the table
within 30sec or so. This doesn't happen - the table remains empty
for as long as I've watched (3 minutes or more).

However, if I start a corresponding server process up (nc -l -k 1234),
wesley appears fairly quickly in the table -- but I also get a
lot of block entries in the log (connection, not syn packets), a lot of
the connections are missed (shown by the loop counter received at the
server end), and the nc program pair hangs frequently. A typical 'block'
log entry would be

19:11:11.259483 rule 6/0(match): block in on dc0: 192.168.0.6.55516 >
192.168.0.1.1234: FP 0:6(6) ack 1 win 33304 11631051[|tcp]>

This shows a match against the default-to-block rule (rule 6) - so
something strange has happened to the 'keep state' operation.

This behaviour isn't at all what I expected to see.

First question then is why does the behaviour of pf depend on whether or
not a server process is listening? Surely it shouldn't, and I've seen no
mention in the documentation of this.

Second question is why does pf seemingly not notice repeated connect
requests when there's no server listening?

Third question is why is pf blocking anything at all anyway with this rule?

Oh yes, this is FreeBSD 6.1-RELEASE btw.

Can anyone help me understand what's happening please? Thanks in advance
for any pointers.

And thanks too for reading this far :-)