Re: impossible rc.d ordering problem with stf and pf ?
- From: Max Laier <max@xxxxxxxxxxxxxx>
- Date: Sun, 28 Jan 2007 18:15:29 +0100
On Sunday 28 January 2007 16:33, Richard Coleman wrote:
Bruce M. Simpson wrote:
Pete French wrote:
Am trying to solve a little problem with 'pf'. I have a ruleset
which has some firewall rules for the IPv6 interface stf0. This
works fine, except when I rreboot the machine, as the pf script is
run before the network_ipv6 script - so stf0 does not exist. but I
cannot work out how to arrange for stf0 to be created before the pf
script is run - as network_ipv6 requires 'routing', but the pf
script says it must be run before 'routing', if I am reading the
'REQUIRE' and 'BEFORE' lines correctly.
Just chiming in to confirm that this problem definitely exists.
I don't have a solution, however, my IPv6 tunnels at home have all
expired, so I may well get spare cycles to look at this the same time
that I get spare cycles to revive the tunnels.
BMS
Essentially the same problem exists with pf and ppp. The tun device
(on which most of my pf rules depend) does not yet exist when pf is
started.
Apparently, someone has looked at this before, since there are commands
to resync pf and ipf inside the rc.d script for ppp (in ppp_postcmd).
But this still doesn't work, since ppp is still negotiating the
connection when this function is run, so pf fails a second time. My
solution was to jam a "sleep 15" inside ppp_postcmd() right before the
point the commands to reload pf and ipf are run. It's major ugly, but
it works. Hopefully someone will find a better solution to these
problems.
In oder to solve these problems you have to understand why pf is failing.
This can be for three reasons:
1) You use the interface name as address w/o dynamic lookup. i.e. "...
from stf0 ..."
2) You use "set loginterface sft0"
3) You use the interface with ALTQ "altq on stf0 ..." (now this doesn't
work and wouldn't be a good idea either, but for tun0 it makes slightly
more sense).
To 1 and 2 there is a simple sollution: Don't do that then! 1 can easily
be defused by adding parentheses. i.e. "... from (stf0) ...". If more
control is required you have to write explicit addresses in your
configuration anyway. 2 is obsolete by "pfctl -vvsI -i stf0" which has
all the counters for all the interfaces. ALTQ is the only remaining
problem. I did do some initial patches to tear down altq on interface
removal, which could be extended to work the other way 'round on
interface arrival - if only I had more time :-\
--
/"\ Best regards, | mlaier@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Attachment:
pgpm5EqgfTxlI.pgp
Description: PGP signature
- Follow-Ups:
- Re: impossible rc.d ordering problem with stf and pf ?
- From: Pete French
- Re: impossible rc.d ordering problem with stf and pf ?
- From: Richard Coleman
- Re: impossible rc.d ordering problem with stf and pf ?
- References:
- impossible rc.d ordering problem with stf and pf ?
- From: Pete French
- Re: impossible rc.d ordering problem with stf and pf ?
- From: Bruce M. Simpson
- Re: impossible rc.d ordering problem with stf and pf ?
- From: Richard Coleman
- impossible rc.d ordering problem with stf and pf ?
- Prev by Date: Re: impossible rc.d ordering problem with stf and pf ?
- Next by Date: Re: rd.d/power_profile: dev.cpu.0.cx_supported doesn't exist
- Previous by thread: Re: impossible rc.d ordering problem with stf and pf ?
- Next by thread: Re: impossible rc.d ordering problem with stf and pf ?
- Index(es):
Relevant Pages
|
|
