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 -- 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.
