On Tue, Apr 26, 2016 at 12:00 PM, Tobias Klauser <[email protected]> wrote: > On 2016-04-26 at 10:47:18 +0200, Vadim Kochan <[email protected]> wrote: >> On Tue, Apr 26, 2016 at 10:30:19AM +0200, Tobias Klauser wrote: >> > On 2016-04-25 at 16:55:53 +0200, Vadim Kochan <[email protected]> wrote: >> > > On Mon, Apr 25, 2016 at 11:21:57AM +0200, Tobias Klauser wrote: >> > > > On 2016-04-22 at 23:53:01 +0200, Vadim Kochan <[email protected]> >> > > > wrote: >> > > > > Hi, >> > > > > >> > > > > I am thinking about to add dump of flows to stdout. It seems OK if >> > > > > to use similar table format like in curses mode by default, but in >> > > > > case >> > > > > of src peer info (2 lines per flow) the output processing by >> > > > > external scripts >> > > > > or text processors might be too complex with considering of row >> > > > > numbering. >> > > > > >> > > > > So here are my conclusions: >> > > > > >> > > > > 1) Default is OK - 1 line per flows with DST info only. >> > > > > >> > > > > 2) If "-s" option is specified - print 2 lines per flows like in >> > > > > curses mode. >> > > > > >> > > > > 3) Add "-o, --oneline" option to print src & dst info in 1 row, even >> > > > > if it will be overflowed in next line - this is just for external >> > > > > text >> > > > > processing. >> > > > >> > > > I'd strongly prefer this way of implementing it - similar to the -c >> > > > option for ifpps. IMO, there's bo reason to care about line overflows, >> > > > as the main target will be script processing. >> > > > >> > > > > Also may be it would be useful to print empty columns with "*" or "-" >> > > > > it will be more visually readable (probably in curses mode too) and >> > > > > also be >> > > > > processed by awk. >> > > > >> > > > Either this (just make sure it's a character that can't appear inside a >> > > > field), or separate the columns using comma or semicolon. >> > > >> > > >> > > I) This is an example of default output 'flowtop -d': >> > > >> > > PROCESS PID PROTO STATE TIME ADDRESS >> > > PORT GEO BYTES RATE >> > > >> > > * * tcp TIME-WAIT 50s mc.yandex.ru >> > > https RUS 476 * >> > > * * tcp TIME-WAIT 51s host10.rax.ru >> > > http RUS 164 * >> > > firefox 29425 tcp ESTABLISHED 53s 74.117.181.52 >> > > http USA 1.7kB * >> > > * * tcp TIME-WAIT 52s bs.yandex.ru >> > > http RUS 2.2kB * >> > > * * tcp TIME-WAIT 51s host69.rax.ru >> > > http RUS 1.3kB * >> > > firefox 29425 tcp ESTABLISHED 53s 74.117.181.52 >> > > http USA 1.9kB * >> > > * * tcp TIME-WAIT 51s host10.rax.ru >> > > http RUS 533 * >> > > >> > > II) This is an example of output 'flowtop -ds', each flow entry >> > > separated with additional empty line to easy separate src & dst: >> > > >> > > >> > > PROCESS PID PROTO STATE TIME ADDRESS >> > > PORT GEO BYTES RATE >> > > mutt 30420 tcp ESTABLISHED 1m angus-think >> > > 48154 * 3.9kB * >> > > --> lo-in-f108.1e100.net >> > > imaps USA 95.7kB * >> > > >> > > * * tcp ESTABLISHED 21h angus-think >> > > 42480 * 3.9MB * >> > > --> 194.44.4.115 >> > > https UKR 191.0MB * >> > > >> > > skype 20044 tcp ESTABLISHED 48m angus-think >> > > 50148 * 302.7kB * >> > > --> 157.55.130.153 >> > > 40021 USA 187.8kB * >> > > >> > > skype 20044 tcp ESTABLISHED 7h angus-think >> > > 51028 * 7.5kB * >> > > --> 91.190.217.47 >> > > 12350 LUX 4.9kB * >> > > >> > > >> > > What do you think ? >> > >> > Two things come to mind: >> > >> > 1) bytes and rate - if applicable - should be printed as raw byte count >> > (not shortened to kB, MB etc) in the stdout mode. This makes reusing >> > the values in scripts much easier and can still be converted to other >> > units if needed. >> I agree. >> > >> > 2) For the dump mode I wouldn't distinguish between one- and two-line >> > mode (i.e. the -s option), but always print all information for a >> > particular flow on one line, also the source. Again, this makes >> > parsing using a script (which will be the primary usage for this >> > feature) much easier. >> The reason why I did so is that it might be useful to have >> flows info in text format, send it via email or do grep (even with src >> info grep might be specified with context info (-A/-B options)). >> And later add -o option (oneline - in future we might have options >> to select columns and columnt might be added more), and also add >> separately CSV & JSON output formatting. Actually thats are my all args. >> So I still think that it might be good to support stdout & interactive >> modes in well readable formats. > > In my opinion this would just needlessly blow up complexity (many > comamnd line options influencing only small parts of the functionality). > I'd rather have one well-defined mode which contains all available > information and this can then be used to extract the necessary > information using a script. In my opinion there is no use for an > "readable" interactive stdout mode, that's what we have the curses mode > for, no? > > I'd really prefer to keep this as simple as possible. > > Thanks > Tobias
OK, I will try to do it simple, so lets try again ... I will just print to stdout in the format like in the default for curses mode but with all columns in one line and with raw bytes/rates ? Thanks, -- You received this message because you are subscribed to the Google Groups "netsniff-ng" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
