Re: fbsd 6.2 pf starts -- but not on boot
hi, > though the prob's been fixed, just to ack/comment ... the issue 4 me > was that pf itself was not starting, not that it had started but the > rules were not loaded, or some such ... Reloading the rules is supposed to allow pf to pick-up new interfaces, which is why it's done after ppp is started. I was wondering if Volker had a valid reason for thinking there is a problem, or whether he was speculating from incomplete knowledge. As regards pf not starting, in another sub-thread you seem to be saying that the underlying problem was an irregularity in ppp.conf. ppp.conf is not read until *after* pf starts-up, so can't explain pf's not starting. argh. well, i'm awash in subtleties. atm, i'm choosing to not 'look a gift horse in the mouth', and be happy that it's up-n-running/working again. as for /understanding/ why, that'll require reading & beer. which is why weekends were invented ;-) thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
On Tue, 5 Jun 2007 20:31:59 -0700 snowcrash+freebsd <[EMAIL PROTECTED]> wrote: > hi, > > > Have you any particular reason to think that this is really a > > problem? Given that /etc/rc.d/ppp automatically reloads the pf > > rules after the tun device is created. > > though the prob's been fixed, just to ack/comment ... the issue 4 me > was that pf itself was not starting, not that it had started but the > rules were not loaded, or some such ... Reloading the rules is supposed to allow pf to pick-up new interfaces, which is why it's done after ppp is started. I was wondering if Volker had a valid reason for thinking there is a problem, or whether he was speculating from incomplete knowledge. As regards pf not starting, in another sub-thread you seem to be saying that the underlying problem was an irregularity in ppp.conf. ppp.conf is not read until *after* pf starts-up, so can't explain pf's not starting. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
hi, Funny thing is, I doubt I'd have noticed it without your blank line! heh. well, glad i could help! i live to serve ;-) cheers! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
On Tue, 5 Jun 2007, snowcrash+freebsd wrote: > well, per Ian's catch/suggestion, removing the 'blank line' from my > "ppp.conf", and moving, > >add default HISADDR > > to the "ppp1:" connection stanza seems to have done the trick! pf > loads properly on reboot. > > swithc it back, and it does not. > > so, guessing, it's the lack of a default root as a result of the blank line. Actually, turns out I was speaking 'historically'; ppp no longer treats blank lines as section terminators - and may not have for years! :) /usr/share/examples/ppp/ppp.conf.sample still begins using that style, with # comment lines within sections and blank lines only at end, but also points out early on that blank lines are ignored, and some later example sections indeed use that style. To add to the confusion, I'm lately using ppp's successor mpd instead, which does still use blank lines to terminate conf file sections .. So the problem was really more the position of your 'add default' line; it's needed within the section you've specified to run, here ppp1: Funny thing is, I doubt I'd have noticed it without your blank line! > the "gotcha" here was that, according to my notes, i *HAD* > checked/ensure that my default routes were correctly initialized > (with "netstat -nr"), but, apparently, BEFORE i'd naively/mistakenly > added that blank line. > > woohoo! Glad it goes, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
hi, Have you any particular reason to think that this is really a problem? Given that /etc/rc.d/ppp automatically reloads the pf rules after the tun device is created. though the prob's been fixed, just to ack/comment ... the issue 4 me was that pf itself was not starting, not that it had started but the rules were not loaded, or some such ... thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
On Tue, 05 Jun 2007 21:59:13 +0200 Volker <[EMAIL PROTECTED]> wrote: > Hi snow, > > aha. does that suggest that i'm simply not waiting long enough? > > your following comments suggest otherwise, iiuc, that i need to > > proactively _do_ something different ... > > It's not _you_ aren't waiting too long. It's at the time pf is being > loaded, the interface pf want's to filter on does not yet exist. See > it as a wrong load order. Have you any particular reason to think that this is really a problem? Given that /etc/rc.d/ppp automatically reloads the pf rules after the tun device is created. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
well, per Ian's catch/suggestion, removing the 'blank line' from my "ppp.conf", and moving, add default HISADDR to the "ppp1:" connection stanza seems to have done the trick! pf loads properly on reboot. swithc it back, and it does not. so, guessing, it's the lack of a default root as a result of the blank line. the "gotcha" here was that, according to my notes, i *HAD* checked/ensure that my default routes were correctly initialized (with "netstat -nr"), but, apparently, BEFORE i'd naively/mistakenly added that blank line. woohoo! and, thanks all for the add'l comments -- good pointers on anchors and pf operation in general. archiving this thread! :-) cheers. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
hi, Hello, it's your niggly proofreader :-D (and fellow Stephenson fan) !! If you really have that blank line before 'add default HISADDR' above, then it marks the end of your default section. The 'add default' and the two lines following will not be executed. I expect you'll want the 'add default' line as the last in your ppp1: section anyway; the other two could go in either, but I'd opt for the default block myself. i had not realized that blank lines were 'read for real'. it's now been removed ... and i've moved the 'add default' to the connection ... I'm again unsure whether it's related to your pf problem, rusted-on ipfw here, but my connections tend to work better with a default route .. recently converted to pf, and been pretty pleased/impressed with it so far. a few gotchas, mainly due to not (yet) having read the /right/ man page, bu i'm makin progress! now, to clean up a bit more, and see if all's better ... thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
Hi snow,
On 06/05/07 00:37, snowcrash+freebsd wrote:
> On 6/4/07, Volker <[EMAIL PROTECTED]> wrote:
>> without seeing your pf.conf ruleset,
>
> happy to send/post if required/helpful ...
I don't think it's required for now.
>> I guess you're using a ppp
>> connection to your upstream provider and firewalling on the tunX
>> interface (using tun0 as $ext_if).
>
> you're absolutely correct here.
>
>> As FreeBSD boots up, this interface does not yet exist when pf is
>> loaded.
>
> clear.
>
>> As soon as ppp is loaded and interface tun0 has been created,
>> pf will happily load your ruleset.
>
> aha. does that suggest that i'm simply not waiting long enough? your
> following comments suggest otherwise, iiuc, that i need to proactively
> _do_ something different ...
It's not _you_ aren't waiting too long. It's at the time pf is being
loaded, the interface pf want's to filter on does not yet exist. See
it as a wrong load order.
The only thing you could do is only using interfaces which do exist at
boot-up time. tun, ppp and ng interfaces are created a bit later (by
default). You could avoid using dynamic interfaces in your ruleset
(which is not always possible). For example you could filter on the
interface group 'pass out on tun from any to any port http keep state'
should happily be parsed and loaded at boot time, even while no tun
interface does exist. As soon as you're trying to get the IP address
of such interface (rdr rules most likely), pf will fail with a 'device
not configured' error message (or the like).
>> The solution is to either have pf rules loaded late (later than ppp is
>> started)
>
> clearly, simply including pf-related items in rc.conf after
> pppoe-related items is not sufficient.
>
> i'll take a look at "rcorder" ... which i wasn't aware of at all. thanks!
The clearest solution is to have a pf ruleset without any dynamic
interfaces included but having anchors included to later fill the
rules as soon as the dynamic interfaces are created. As that is one
thing on my 2do list for a long time, I don't have any good examples
for that. The OpenBSD pf FAQ does contain a bit about this.
If you want to avoid using anchors, you can use a very quick and dirty
solution by just symlinking /etc/rc.d/pf to /usr/local/etc/rc.d. A bit
better (just a bit) is to create a new rc file in /usr/local/etc/rc.d
which may contain something like:
file: /usr/local/etc/rc.d/pf-late
#!/bin/sh
# PROVIDE: pf-late
# REQUIRE: NETWORKING DAEMON
/etc/rc.d/pf ${1}
#EOF
This script will run after all networking parts and all daemon
processes have been loaded and will load pf rules. Using that, pf
rules will be loaded twice: the first (regular) time will fail and the
2nd time will most likely succeed. Keep in mind this is just a quick
and dirty workaround.
>
>> or use anchors and load ext rules into the anchor when the
>> ppp interface is up.
>
> i hadn't thought of using anchors in this fashion.
>
> i'm off to google, but any good examples you can reference?
>
>> The easier is to have the rules loading late
>> (check using rcorder) but this may also fail if something goes wrong
>> with ppp.
>
> i /thought/ i'd dealt with the intfc/ppo/pf ordering issue, configuring,
>
> cat /etc/ppp/ppp.linkup
>
> ppp1:
> ! sh -c "/sbin/pfctl -ef /usr/local/etc/pf/pf.conf"
That might work but I would try to have it running in the background
(!bg) as while forking a foreground process, ppp will be blocked for
that time.
> !bg sh -c "echo `/bin/date` `/etc/bin/ip` ppp.linkup >>
> /etc/ppp/log"
>
>
> cat /etc/ppp/ppp.linkdown
>
> ppp1:
> !bg route delete HISADDR ppp1
> !bg pfctl -F all -d
>
>
> cat /etc/ppp/ppp.conf
>
> default:
> set device PPPoE:sis1:
> set speed sync
> set ctsrts off
> set dial
> set login
> set cd 10
> set timeout 0
> set redial 0 0
> enable lqr
> set lqrperiod 20
> set log Phase tun command
>
> add default HISADDR
> enable tcpmssfixup
> disable dns
>
> ppp1:
> set authname [EMAIL PROTECTED]
> set authkey
> set MRU 1492
> set MTU 1492
>
>
> are these NOT supposed to address/solve the problem? or are the configs
> wrong?
Other then the bg issue, I don't have an idea why your current config
does not work. You may check (just a guess) if pf does see that
interface at the time the linkup script is executed by inserting
`pfctl -sI' and check the output.
If running that (pf) script in the background does not solve your
problem, you may go the quick workaround by using a 'pf-late' script.
If you really want to have it clear and well designed (and
Re: fbsd 6.2 pf starts -- but not on boot
On Mon, 4 Jun 2007 15:37:25 -0700 snowcrash+freebsd <[EMAIL PROTECTED]> wrote: > cat /etc/ppp/ppp.conf > > default: > set device PPPoE:sis1: > set speed sync > set ctsrts off > set dial > set login > set cd 10 > set timeout 0 > set redial 0 0 > enable lqr > set lqrperiod 20 > set log Phase tun command > > add default HISADDR > enable tcpmssfixup > disable dns > > ppp1: > set authname [EMAIL PROTECTED] > set authkey > set MRU 1492 > set MTU 1492 > > > are these NOT supposed to address/solve the problem? or are the > configs wrong? Hello, it's your niggly proofreader (and fellow Stephenson fan) again. If you really have that blank line before 'add default HISADDR' above, then it marks the end of your default section. The 'add default' and the two lines following will not be executed. I expect you'll want the 'add default' line as the last in your ppp1: section anyway; the other two could go in either, but I'd opt for the default block myself. I'm again unsure whether it's related to your pf problem, rusted-on ipfw here, but my connections tend to work better with a default route .. Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
hi, The ppp rc.d script resyncs pf and ipfilter, to pick-up new interfaces, so that shouldn't be needed. as i'm not entirely clear on the order/function of all yet, you're saying that's /not/ related to the not-starting-up-on-boot problem i'm seeing, and thus i shouldn't bother with the rcoder/anchor options mentioned? thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
hi, I really don't know whether this might be related to your problem, but my proofreading eye was distracted by this in your rc.conf: > # PPP > ppp_enable="YES" > ppp_mode="ddial" > ppp_nat="NO" > ppp_profile="ppp`" What rc would make of that backtick inside quotes, I know not .. wow! good eye. checked, and that's some cp-n-paste weirdness, or my fat thumbs. the line actually is, > ppp_profile="ppp1" thanks for the check! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
On Mon, 04 Jun 2007 23:17:38 +0200 Volker <[EMAIL PROTECTED]> wrote: > without seeing your pf.conf ruleset, I guess you're using a ppp > connection to your upstream provider and firewalling on the tunX > interface (using tun0 as $ext_if). > > As FreeBSD boots up, this interface does not yet exist when pf is > loaded. As soon as ppp is loaded and interface tun0 has been created, > pf will happily load your ruleset. > > The solution is to either have pf rules loaded late (later than ppp is > started) or use anchors and load ext rules into the anchor when the > ppp interface is up. The easier is to have the rules loading late > (check using rcorder) but this may also fail if something goes wrong > with ppp. The ppp rc.d script resyncs pf and ipfilter, to pick-up new interfaces, so that shouldn't be needed. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
On 4 Jun 2007 14:03:20 -0700 snowcrash+freebsd <[EMAIL PROTECTED]> wrote: > on boot, pf is, apparently, not starting. > > but, if i exec > > /etc/rc.d/pf start > > immediately after boot to prompt is done, then all's OK. > > the only related (?) messages -- error or otherwise -- i've found are > on startup. I really don't know whether this might be related to your problem, but my proofreading eye was distracted by this in your rc.conf: > # PPP > ppp_enable="YES" > ppp_mode="ddial" > ppp_nat="NO" > ppp_profile="ppp`" What rc would make of that backtick inside quotes, I know not .. cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
On 6/4/07, Volker <[EMAIL PROTECTED]> wrote: without seeing your pf.conf ruleset, happy to send/post if required/helpful ... I guess you're using a ppp connection to your upstream provider and firewalling on the tunX interface (using tun0 as $ext_if). you're absolutely correct here. As FreeBSD boots up, this interface does not yet exist when pf is loaded. clear. As soon as ppp is loaded and interface tun0 has been created, pf will happily load your ruleset. aha. does that suggest that i'm simply not waiting long enough? your following comments suggest otherwise, iiuc, that i need to proactively _do_ something different ... The solution is to either have pf rules loaded late (later than ppp is started) clearly, simply including pf-related items in rc.conf after pppoe-related items is not sufficient. i'll take a look at "rcorder" ... which i wasn't aware of at all. thanks! or use anchors and load ext rules into the anchor when the ppp interface is up. i hadn't thought of using anchors in this fashion. i'm off to google, but any good examples you can reference? The easier is to have the rules loading late (check using rcorder) but this may also fail if something goes wrong with ppp. i /thought/ i'd dealt with the intfc/ppo/pf ordering issue, configuring, cat /etc/ppp/ppp.linkup ppp1: ! sh -c "/sbin/pfctl -ef /usr/local/etc/pf/pf.conf" !bg sh -c "echo `/bin/date` `/etc/bin/ip` ppp.linkup >> /etc/ppp/log" cat /etc/ppp/ppp.linkdown ppp1: !bg route delete HISADDR ppp1 !bg pfctl -F all -d cat /etc/ppp/ppp.conf default: set device PPPoE:sis1: set speed sync set ctsrts off set dial set login set cd 10 set timeout 0 set redial 0 0 enable lqr set lqrperiod 20 set log Phase tun command add default HISADDR enable tcpmssfixup disable dns ppp1: set authname [EMAIL PROTECTED] set authkey set MRU 1492 set MTU 1492 are these NOT supposed to address/solve the problem? or are the configs wrong? Mikhail Goriachev <[EMAIL PROTECTED]> Just a shot in the dark. You are probably putting hostnames in your pf.conf instead of IPs. PF starts before Bind. So it can't resolve hostnames in the rules and hence doesn't start. heh. a good call, but, i'd already made THAT mistake a month or so ago. ;-) thanks though! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
snowcrash+freebsd wrote: hi, i've fbsd 6.2R/p5, with pf compiled into a custom kernel. on boot, pf is, apparently, not starting. but, if i exec /etc/rc.d/pf start immediately after boot to prompt is done, then all's OK. the only related (?) messages -- error or otherwise -- i've found are on startup. any ideas/suggestions as to what might be the prob? and/or how to troubleshoot? Just a shot in the dark. You are probably putting hostnames in your pf.conf instead of IPs. PF starts before Bind. So it can't resolve hostnames in the rules and hence doesn't start. Regards, Mikhail. -- Mikhail Goriachev Webanoide Telephone: +61 (0)3 62252501 Mobile Phone: +61 (0)4 38255158 E-Mail: [EMAIL PROTECTED] Web: www.webanoide.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fbsd 6.2 pf starts -- but not on boot
On 06/04/07 23:03, snowcrash+freebsd wrote: > hi, > > i've fbsd 6.2R/p5, with pf compiled into a custom kernel. > > on boot, pf is, apparently, not starting. > > but, if i exec > > /etc/rc.d/pf start > > immediately after boot to prompt is done, then all's OK. > > the only related (?) messages -- error or otherwise -- i've found are > on startup. > > any ideas/suggestions as to what might be the prob? and/or how to > troubleshoot? > > thanks! > > for reference, from console output @ startup, > > > ... > sis0: link state changed to UP > sis1: link state changed to UP > lo0: flags=8049 mtu 16384 >inet6 fe80::1%lo0 prefixlen 64 sscopeid 0x5 >inet6 ::1 prefisxlen 128 >inet2 127.0.0.1 netma:sk 0xff00 > sis0: flags=8843l mtu 149k2 >options=48s >inet 10.0.0.10 netmask 0xfaf00 broadcastt 10.0.0.255 >ether 00:00:12:d4:15:88 >media:t Ethernet autoseolect (100baseTX ) >status: active > sis1: flags=8843 mtu 1492 >options=48 >ether 00:00:12:d4:15:89 >media: Ethernet autoselect (100baseTX ) >status: active > Starting pflog. > pflog0: promiscuous mode enabled > Enabling pf. > Jun 4 13:38:11 pflogd[479]: [priv]: msg PRIV_OPEN_LOG received > pfctl: DIOCSETSTATUSIF > pf enabled ... snow, without seeing your pf.conf ruleset, I guess you're using a ppp connection to your upstream provider and firewalling on the tunX interface (using tun0 as $ext_if). As FreeBSD boots up, this interface does not yet exist when pf is loaded. As soon as ppp is loaded and interface tun0 has been created, pf will happily load your ruleset. The solution is to either have pf rules loaded late (later than ppp is started) or use anchors and load ext rules into the anchor when the ppp interface is up. The easier is to have the rules loading late (check using rcorder) but this may also fail if something goes wrong with ppp. HTH Volker ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
