Dan Mahoney, System Admin <[EMAIL PROTECTED]> wrote: > Even if I add the "flush" command directly to /etc/ipfw.rules, and run > ipfw -f /etc/ipfw.rules right from the command line, my connection gets > dropped and the rest of the commands do not run. > In experimenting a bit more, I've found that I can do: > nohup ipfw -f /etc/ipfw.rules > This allows the rest of the ipfw command to run, but the HUP-on-disconnect > still doesn't explain why the command doesn't even finish running.
If I understands rightly you need -q option. ipfw(8): -q While adding, zeroing, resetlogging or flushing, be quiet about actions (implies -f). This is useful for adjusting rules by exe- cuting multiple ipfw commands in a script (e.g., `sh /etc/rc.firewall'), or by processing a file of many ipfw ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ rules across a remote login session. It also stops a table add ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ or delete from failing if the entry already exists or is not present. If a flush is performed in normal (verbose) mode (with the default kernel configuration), it prints a message. Because all rules are flushed, the message might not be delivered to the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ login session, causing the remote login session to be closed and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the remainder of the ruleset to not be processed. Access to the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ console would then be required to recover. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"