This page is a place where I can dump random things I come across that may be useful to others.
Filtering on a bridge with pf
Suppose that you have three bridged interfaces, fxp0, fxp1, and fxp2. Let's say that you want to pass all traffic on fxp1, but you don't want to pass broadcasts out of fxp2. You might say something like:
pass out quick on fxp1 inet from 172.16.0.0/12 to 172.16.0.0/12
block out quick on fxp2 inet from any to { 172.31.255.255, 255.255.255.255 }
However, unless you've changed some defaults, this won't work, and here's why. Suppose 172.16.0.1 (which is behind fxp0) sends a broadcast packet. This will be matched by the first rule, which will create a state. pf will then see that the packet matches the state and will pass it out through fxp1. Now, here's the interesting bit. Because states aren't bound to interfaces by default (they're “floating”), the state will also allow the packet to pass out of fxp2, rendering the block rule useless! (See below for how to confirm this.)
What you need for this ruleset to work as expected is for the state created by the first rule to be bound to fxp1 so that it doesn't match packets on other interfaces. You can either do this globally using
set state-policy if-bound
or per-rule by adding “keep state (if-bound)” to your pass rules (remember that pf keeps state unless you explicitly tell it not to).
Debugging pf rulesets
If you're trying to figure out why your pf ruleset isn't doing what you think it should, here's a tip. Make each rule log what it's doing by changing, say,
pass in quick on $intf inet proto tcp from any to $foo port 22
to
pass in log (all) quick on $intf inet proto tcp from any to $foo port 22
and similarly for all your other rules. This will make pf log everything matching a rule to its logging interface, pflog0. Omitting “(all)” will make it log only the initial packet which creates a state.
Now reload the ruleset and (as root) run something like
# tcpdump -evNntipflog0
(The important bits here are -e and -ipflog0.) This will show you what packets are being matched by which rule. Look for the rule number in the tcpdump output. To find a rule by its number (say, 42), use
# pfctl -vvsr | grep @42
Binary clock
A JavaScript version of a binary clock.
Pinout of the Compaq 2010c serial cable
The Compaq side of the cable looks like this:
(The pins have been numbered somewhat arbitrarily.) The PC side of the cable looks like this:
This is a standard 9-pin female sub-D connector, with the pins numbered in the usual way.
The connections are shown in the table below.
| PC pin | Compaq pins | Signal |
|---|---|---|
| 1 | 9, 13 | DCD (data carrier detect) |
| 2 | 6 | RxD (receive data) |
| 3 | 11 | TxD (transmit data) |
| 4 | 7 | DTR (data terminal ready) |
| 5 | 8 | SG (signal ground) |
| 6 | 8 | DSR (data set ready) |
| 7 | 12 | RTS (request to send) |
| 8 | 10 | CTS (clear to send) |
| 9 | not connected | RI (ring indicator) |