Why not start the system with one interface down (so you know which way
to route to) then "up" it at the end of the boot sequence and start the
dhclient?
Graham Toal wrote:
Assuming that the problem turns out to be that the dhcp request for
fxp1 is always routed out of fxp1 (makes sense, right?) what can I do
to have it routed out the other interface via bridging? (Remembering
that the solution has to work symmetrically, if in some other deployment
it is the other of the two interfaces which can't see the DHCP server...)
Confirmed that this is the problem. Two ways: 1) I changed /etc/netstart
to bring up the bridge before it configures the interfaces. Dirty, but
it works - and the internal interface still didn't manage to talk to
the dhcp server; and 2) I manually killed the dhclient process for fxp1
once everything was running smoothly from a clean boot, and manually
started "dhclient -d fxp1" - and again, it did not talk to the dhcp
server even though the bridge was already running by that point for sure..
I could force the traffic from one interface to the other with pf
and a route-to option, but only if I know which interface the dhcp
server is connected to. Since I cannot make that assumption (it
depends on where in the network the bridge is inserted) I can't see
a solution. Well, short of some really hacky code to scan the output
of ifconfig -A, and rewrite a new version of pf.conf on the fly.
Can anyone think of some ingenious rule for pf that will get me what
I need? This is the last significant stumbling block in a long
project to build a completely idiot-proof spam filter that works
just like a commercial appliance - plug it in and use it, no
config necessary. (Actually the *last* stumbling block will be
a completely idiot-proof installer - or a live CD - but I'll cross
that bridge when I come to it. No pun intended.)
Graham
--
Kevin Frand
Systems Engineer
eFilm
(323) 308-3013
[EMAIL PROTECTED]
