eldamar.org.uk

/

bits

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: Compaq connector (The pins have been numbered somewhat arbitrarily.) The PC side of the cable looks like this: PC connector 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)