-f silently fails if base/frameworks/packet-filter isn't loaded

Description

I know we've been through this before (though searching the tickets in Jira, I couldn't find the thread). But to revisit: the "-f filter" option silently does nothing if base/frameworks/packet-filter isn't loaded (so the scenario here is using -b to suppress its automatic loading). This can lead to seriously confusing behavior. It would be preferable if there's either an error message indicating that the option won't be supported, or if it forced loading of packet-filter.

Environment

None

Activity

Show:
Jon Siwek
September 17, 2018, 8:21 PM
Vern Paxson
June 1, 2015, 6:35 PM

Also, regarding the policy script adding the -f flag: how would the user discover that that's what they need to do (have the policy script loaded) to get the flag? I can see quite a bit of perplexment if Bro just tells the user that the flag doesn't exist without explaining why, if they don't have the script loaded.

Vern Paxson
June 1, 2015, 6:33 PM

While there's an appeal to processing arguments in script-land, because some arguments control basic script processing (e.g., -p), I'm not sure this can be done in a coherent fashion without some significant under-the-hood kludges.

Regarding replacing -f with PacketFilter::filter=XXXX, yuck - I wouldn't want to have to remember that, and there's no ready way for a user to discover this.

I'd be happy settling for -f warning (or exiting) with a statement that without the packet filtering framework loaded, it's a no-op. Though I have a forboding that you're going to tell me that that's actually hard to implement .

Robin Sommer
June 1, 2015, 3:35 PM

If we had that, the '-f' switch would probably be added by the packet
filter script, so it'd be available only when loaded.

I'd like to move argument processing into script-land as well.
Generally, however, I think it would still be good to avoid arguments
controlling script behaviour as much as possible. Main reason is
argument inflation: -f has been historically around but there are
plenty other scripts that in principle could take command-line
arguments as well, which would get messy. And we have the X=Y syntax
already to take care of that.

Seth Hall
June 1, 2015, 3:19 PM

We could alternately take the additional step of moving command line argument processing into Bro scripts. I don’t know how exactly we’d solve this particular problem, but it should be reasonably solvable that way.

.Seth


Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/

Moved

Assignee

Unassigned

Reporter

Vern Paxson

Labels

None

External issue ID

None

Components

Priority

Normal