It's ultimately due to a basic limitation of the OS's handling of command args. The short option -B and it's value are separated by white space, so the shell tokenization uses the white space and strips 's/"s to create an array of tokens fed into ntop. Read your Bash (or whatever shell you use), getopt etc. man page. The long option form --filter-expression="...." is seen as a single token and passed into ntop that way.
Note that this all happens before ntop starts up and there's no easy, portable, way to see the actual command line! Anyway, with the short form, the shell takes this: ./ntop -u nobody -P /var/db/ntop -w 3000 -W 0 -e 50 -n -i fxp1 -b -z -B "tcp and 'ether[1:1]\&0x00\=0'" And feeds it to ntop as: 0. ./ntop 1. -u 2. nobody 3. -P ... 16. -B 17. tcp and 'ether[1:1]\&0x00\=0' When we merge the @ (file) parameters, we create a single string and then run it back through the same logic. This is deliberate as we need to pretend all of the @file parameters came in on the command line. And so we want to handle them the same way. However, since quotes are stripped, items with =s or spaces would cause problems, so we special case these, add "s and 99.94% of the time get what you expect (See main.c, 966ff...). However, having both a SPACE and an EQUALS in the same token throws us off (something I hadn't realized until now). Right now we look for the =s first, then a space. This messes up on your case: -B "tcp and 'ether[1:1]&0x00=0'" which becomes FOUR tokens: -B tcp and 'ether[1:1]&0x00="0'" But, if we flip things and look for the SPACE first and quote the entire token, we mess up this: --filter-expression="tcp and 'ether[1:1]\&0x00\=0'" into "--filter-expression="tcp and 'ether[1:1]\&0x00\=0'"" There is no easy solution. Since the shell ignores the specifics of the long option, provided you have balanced "s/'s, etc. the current logic is much preferable to the flip. However as a simple work-around, if the filter expression itself has an = in it, use the long option format and make sure you use "s: --filter-expression="...." That way the buildargv logic will just treat it as a single option. -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf > Of Cole > Sent: Saturday, April 10, 2004 8:37 AM > To: [EMAIL PROTECTED] > Subject: [Ntop-dev] Ntop bpf filter expressions from command line > > > Hey > > Ive just upgraded from ntop 2.2 to Ntop 3.0 on a FreeBSD 4.9-Stable box. > The problem we are having is with ntops bpf filter expressions > from the command line. > > This particular expression we use with tcpdump and it works fine. > We believe it to be a command line parsing issue because if we > use the http gui and add what we want it works fine. > These are the various command lines we tried that dont work: > ./ntop -u nobody -P /var/db/ntop -w 3000 -W 0 -e 50 -n -i fxp1 -b > -z -B "tcp and 'ether[1:1]\&0x00\=0'" > FATAL ERROR: Unrecognized/unprocessed ntop options...and > ether[1:1]&0x00="0 > > ./ntop -u nobody -P /var/db/ntop -w 3000 -W 0 -e 50 -n -i fxp1 -b > -z -B "tcp and ether[1:1]\&0x00\=0" > FATAL ERROR: Unrecognized/unprocessed ntop options...and ether[1:1]&0x00=0 > > These however run fine: > ./ntop -u nobody -P /var/db/ntop -w 3000 -W 0 -e 50 -n -i fxp1 -b > -z -B "ether[1:1]\&0x00\=0" > ./ntop -u nobody -P /var/db/ntop -w 3000 -W 0 -e 50 -n -i fxp1 -b > -z -B "tcp and port http" > > If we use use the Ntop admin page and change the filter with http > then it works fine - > Filter Expression: tcp and port http and ether[1:1]&0x00=0 > > If anyone could help or suggest fix, it would be greatly appreciated > > Thanks > /Cole > > > > > > _______________________________________________ > Ntop-dev mailing list > [EMAIL PROTECTED] > http://listgateway.unipi.it/mailman/listinfo/ntop-dev _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
