Re: [netsniff-ng] [PATCH] netsniff-ng: increment the pkts_seen after packet type check

[Tobias Klauser]

On 2016-07-21 at 16:42:22 +0200, Paolo Abeni  wrote:
> Currently in receive_to_xmit() pkts_seen is incremented before
> after the packet type check, but failing the latter will cause
> the packet to be ignored, pretty much as if it failed to pass
> the filter.
> This change move the accunting after the check, as is currently
> done in both walk_t3_block() and recv_only_or_dump().
> 
> Signed-off-by: Paolo Abeni 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] packet accounting in netsniff-ng

[Tobias Klauser]

On 2016-07-21 at 16:01:30 +0200, Paolo Abeni  wrote:
> Hi all,
> 
> I have a couple of doubts about packet accounting in netsniff-ng:
> currently in receive_to_xmit() pkts_seen is incremented before the
> packet type check, but failing the latter will cause the packet to be
> ignored, pretty much as if it failed to pass the filter.
> In walk_t3_block() and recv_only_or_dump() the accounting is performed
> after the check, should the receive_to_xmit() do the same ?

Yes, receive_to_xmit() should definitely do the same. The current
behavior is wrong.

> Should pkts_drops be incremented if the packet type filter fails ? 

Yes, I think they should be accounted for as well.

> If there is agreement I can send patches implementing the above.

Would be much appreciated, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] [PATCH] netsniff-ng: skip duplicated packets on loopback device

[Tobias Klauser]

On 2016-07-21 at 15:25:27 +0200, Paolo Abeni  wrote:
> When sniffing on the loopback device, each packet will be seen
> twice, once per direction. To avoid duplicates, explicitly
> skip OUTGOING packets received from loopback, if no packet_type
> filter is explicitly set.
> 
> Signed-off-by: Paolo Abeni 

Applied, thanks a lot Paolo.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 0/2] trafgen: Avoid to use user defined fields for csum

[Tobias Klauser]

On 2016-07-16 at 11:39:42 +0200, Vadim Kochan  wrote:
> It is dangerous to use such fields like 'ihl' and 'len' when calculate csum
> for IPv4 & UDP headers because these fields are set from user. Instead -
> use program calculated values.
> 
> Vadim Kochan (2):
>   trafgen: ipv4: Do not use 'ihl' field when calculate csum
>   trafgen: udp: Do not use 'len' field when calculate csum

Series applied.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] trafgen: ipv4: Set default proto as ipv6-in-ipv4 for ipv6()

[Tobias Klauser]

On 2016-07-15 at 22:21:05 +0200, Vadim Kochan  wrote:
> Set default ip proto field to IPPROTO_IPV6(41) if the higher protocol
> was specified as ipv6().
> 
> Signed-off-by: Vadim Kochan 

Applied, thanks Vadim.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v2 0/3] trafgen: Implement ICMPv4 packet creation - part #2

[Tobias Klauser]

On 2016-07-13 at 00:01:52 +0200, Vadim Kochan  wrote:
> Add ICMPv4 protocol header creating.
> 
> Changed echorequest to echo-request, and echoreply to echo-reply
> which looks more readable.
> 
> The following ICMPv4 parameters are supported:
> 
> type
> code
> csum
> mtu
> seq
> id
> addr
> 
> v2:
> 1) Drop patch for split echorequest with "-" sign
> 
> 2) Removed keywords with special icmpv4 message type parameters except
>MTU & Address.
> 
> Vadim Kochan (3):
>   trafgen: l3: Add creating ICMPv4 header
>   trafgen: parser: Add function to build ICMPv4 header
>   trafgen: man: Add description for icmpv4() function

Series squashed and applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 0/6] trafgen: Implement ICMPv4 packet creation

[Tobias Klauser]

On 2016-06-29 at 11:21:24 +0200, Vadim Kochan <vadi...@gmail.com> wrote:
> Hi Tobias,
> 
> On Sat, Apr 30, 2016 at 6:01 PM, Tobias Klauser <tklau...@distanz.ch> wrote:
> > Hi Vadim
> >
> > Thanks for the series. I'll be travelling for a while starting tomorrow,
> > so it will probably take a while until I get to review the patches.
> >
> > Thanks
> > Tobias
> 
> 
> Will you look on this series ?

Sorry for taking so long with the review - quite busy times here :(
Please see my comments on the individual patches.

Thanks a lot for your patience!

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 3/6] trafgen: parser: Split echorequest & echoreply with "-"

[Tobias Klauser]

On 2016-04-30 at 16:39:17 +0200, Vadim Kochan  wrote:
> Change echorequest to echo-request, and echoreply to echo-reply
> which looks more readable.
> 
> Signed-off-by: Vadim Kochan 

NAK, I think it's OK the way it currently is. All other "2-word"
keywords also don't have a separating dash.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 1/6] trafgen: parser: Split [e]type to separate keywords

[Tobias Klauser]

On 2016-04-30 at 16:39:15 +0200, Vadim Kochan  wrote:
> Split [e]etype to separate 'type' & 'etype' keywords,
> the reason is that 'type' might be used in other protocol
> headers (e.g. ICMP).
> 
> Signed-off-by: Vadim Kochan 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 2/6] trafgen: parser: Replace 'mtype' by 'type'

[Tobias Klauser]

On 2016-04-30 at 16:39:16 +0200, Vadim Kochan  wrote:
> After splitting etype & type to different tokens it is possible
> to use 'type' for ICMP type field which is used by RFC.
> 
> Signed-off-by: Vadim Kochan 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] netsniff-ng: Create out pcap only if first packet passed

[Tobias Klauser]

On 2016-05-16 at 18:58:21 +0200, Vadim Kochan  wrote:
> If all packets did not pass the filter then output pcap
> file will be created with pcap header, which might be not what user
> expect - to see only interested pcap files.

IMO, an output file should always be created, even if it contains no
packets. Otherwise it's not entirely obvious whether there was an error
in netsniff-ng or whether there just weren't any passed packets. Also,
in case the file can't be created (e.g. due to lacking permissions) and
the first packet to be written only arrives a large amount of time after
program start, the user would only notice by then.

BTW, an empty pcap opens just fine in e.g. Wireshark.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] [PATCH] man: netsniff-ng: Fix usage example description

[Tobias Klauser]

On 2016-06-21 at 18:20:35 +0200, Hisao Tanabe  wrote:
> Fix the input device name that is used in the description of the usage
> example.
> 
> Signed-off-by: Hisao Tanabe 

Applied, thanks a lot.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] netsniff-ng: pcap_io: Print unsupported magic number

[Tobias Klauser]

On 2016-05-16 at 19:32:46 +0200, Vadim Kochan  wrote:
> It might be more understandable to print unsupported
> pcap magic number in hexadecimal format.
> 
> Signed-off-by: Vadim Kochan 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: flowtop: How should be src info printed in stdout dump mode

[Tobias Klauser]

On 2016-04-26 at 12:24:45 +0200, Vadim Kochan <vadi...@gmail.com> wrote:
> On Tue, Apr 26, 2016 at 12:00 PM, Tobias Klauser <tklau...@distanz.ch> wrote:
> > On 2016-04-26 at 10:47:18 +0200, Vadim Kochan <vadi...@gmail.com> 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 <vadi...@gmail.com> 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 <vadi...@gmail.com> 
> >> > > > 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
> >> > >
> >> > > * *   tcpTIME-WAIT50s mc.yandex.ru 
> >> > >   httpsRUS476  *
> >> > > * *   tcpTIME-WAIT51s host10.rax.ru
> >> > >   http RUS164  *
> >> > > firefox   29425   tcpESTABLISHED  53s 74.117.181.52
> >> > >   http USA  1.7kB  *
> >> > > * *   tcpTIME-WAIT52s bs.yandex.ru 
> >> > >   http RUS  2.2kB  *
> >> > > * *   tcpTIME-WAIT51s host69.rax.ru
> >> > >   http RUS  1.3kB  *
> >> > > firefox   29425   tcpESTABLISHED  53s 74.117.181.52
> >> > >   http USA  1.9kB  *
> >> > > * *   tcpTIME-WAIT51s host10.rax.ru
> >> > >   http RUS533  *
> >> > >
> >> > > 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 

[netsniff-ng] Re: [PATCH 5/8] flowtop: Remove unused args in draw_flow_entry(...)

[Tobias Klauser]

On 2016-04-26 at 09:47:19 +0200, Vadim Kochan  wrote:
> Remove unused "screen" & "line" arguments in draw_flow_entry(...)
> function.
> 
> Signed-off-by: Vadim Kochan 

This does not really influence the rest of the series, so I already
applied this, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: flowtop: How should be src info printed in stdout dump mode

[Tobias Klauser]

On 2016-04-25 at 16:55:53 +0200, Vadim Kochan <vadi...@gmail.com> 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 <vadi...@gmail.com> 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 
>   
>   
> 
> * *   tcpTIME-WAIT50s mc.yandex.ru
>httpsRUS476  * 
> * *   tcpTIME-WAIT51s host10.rax.ru   
>http RUS164  * 
> firefox   29425   tcpESTABLISHED  53s 74.117.181.52   
>http USA  1.7kB  * 
> * *   tcpTIME-WAIT52s bs.yandex.ru
>http RUS  2.2kB  * 
> * *   tcpTIME-WAIT51s host69.rax.ru   
>http RUS  1.3kB  * 
> firefox   29425   tcpESTABLISHED  53s 74.117.181.52   
>http USA  1.9kB  * 
> * *   tcpTIME-WAIT51s host10.rax.ru   
>http RUS533  * 
> 
> 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   tcpESTABLISHED   1m angus-think 
>48154*3.9kB  * 
>   --> lo-in-f108.1e100.net
>imapsUSA 95.7kB  * 
> 
> * *   tcpESTABLISHED  21h angus-think 
>42480*3.9MB  * 
>   --> 194.44.4.115
>httpsUKR191.0MB  * 
> 
> skype 20044   tcpESTABLISHED  48m angus-think 
>50148*  302.7kB  * 
>   --> 157.55.130.153  
>40021USA187.8kB  * 
> 
> skype 20044   tcpESTABLISHED   7h angus-think 
>51028*7.5kB  * 
>   --> 91.190.217.47   
>12350LUX  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 std

[netsniff-ng] Re: flowtop: How should be src info printed in stdout dump mode

[Tobias Klauser]

On 2016-04-22 at 23:53:01 +0200, Vadim Kochan  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.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v3 0/6] flowtop: Layout change to 1-row view (part #2)

[Tobias Klauser]

On 2016-04-21 at 20:47:37 +0200, Vadim Kochan  wrote:
> This is a 2nd part of series about changing flowtop layout to 1-row
> view. This version is mostly a refactoring of flows refreshing to
> make it more generic by using UI table API.
> 
> v3:
> 1) Fixed headers including
> 
> 2) Fixed trailing tab in ui.c
> 
> 3) Replaced panic(...) by bug_on(true) in ui table column lookup function.

Note that you can also use bug() as a shorthand for bug_on(true). I
changed your patches accordingly before applying.

> 4) Clear screen on init.
> v2:
> 1) Add UI table widget with generic implementation for
>print list items in table style. Add new UI module with
>generic table API.
> 
> 2) Add Linux-like list API used from liburcu but with redefinitions
>to the Linux naming.
> 
> 3) Get rid of clear & refresh screen each time while flows printing.
> 
> Vadim Kochan (6):
>   list: Add re-defined double-linked list API from liburcu
>   ui: Implement UI table for flows printing
>   flowtop: Use new UI table API for draw flows list
>   ui: Print empty rows when clear table
>   flowtop: Get rid of clear() & refresh() calls
>   flowtop: Simplify flows refresh delay

Series applied, thanks Vadim!

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] flowtop: Fix compilation error when build without geoip

[Tobias Klauser]

On 2016-04-22 at 06:05:47 +0200, Vadim Kochan  wrote:
> Commit (f61f39d geoip: Allow to get country 3-code) added
> new helpers without considering HAVE_GEOIP definition.
> 
> Fixed by adding dummy functions for get 3-code country name
> in case if HAVE_GEOIP is not defined.
> 
> Tested only by manualy disabling HAVE_GEOIP in config.h
> and geoip.c compilation in Config file.
> 
> Fixes: f61f39d (geoip: Allow to get country 3-code)
> Reported-by: Daniel Borkmann 
> Signed-off-by: Vadim Kochan 

Applied. Thanks Daniel and Vadim!

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v2 07/11] ui: Implement UI table for flows printing

[Tobias Klauser]

On 2016-04-17 at 19:31:30 +0200, Vadim Kochan  wrote:
> Add new module ui.c which is responsible to render
> different kinds of UI widgets - tables, etc.
> 
> Implemented generic API for print table-like list of elements.
> This table API might be used for print flows in curses or text mode.
> 
> Signed-off-by: Vadim Kochan 

Looks good in general, a few minor nits below.

> ---
>  ui.c | 142 
> +++
>  ui.h |  53 +

How about calling the module ui_table, which is a bit more specific?
Also all function names already start with "ui_table_".

>  2 files changed, 195 insertions(+)
>  create mode 100644 ui.c
>  create mode 100644 ui.h
> 
> diff --git a/ui.c b/ui.c
> new file mode 100644
> index 000..d5fe1a7
> --- /dev/null
> +++ b/ui.c
> @@ -0,0 +1,142 @@
> +/*
> + * netsniff-ng - the packet sniffing beast
> + * Subject to the GPL, version 2.
> + */
> +
> +#include "ui.h"
> +#include "xmalloc.h"
> +
> +#include 

Global headers should come first, i.e.

#include 

#include "ui.h"
#include "xmalloc.h"

> +void ui_table_init(struct ui_table *tbl)
> +{
> + memset(tbl, 0, sizeof(*tbl));
> +
> + getsyx(tbl->y, tbl->x);
> +
> + tbl->rows_y  = tbl->y;
> + tbl->width   = COLS;
> + tbl->col_pad = 1;
> +
> + INIT_LIST_HEAD(>cols);
> +}
> +
> +void ui_table_uninit(struct ui_table *tbl)
> +{
> + struct ui_col *col, *tmp;
> +
> + list_for_each_entry_safe(col, tmp, >cols, entry)
> + xfree(col);
> +}
> +
> +void ui_table_pos_set(struct ui_table *tbl, int y, int x)
> +{
> + tbl->y  = y;
> + tbl->x  = x;
> + tbl->rows_y = y;
> +}
> +
> +static struct ui_col *ui_table_col_get(struct ui_table *tbl, uint32_t id)
> +{
> + struct ui_col *col;
> +
> + list_for_each_entry(col, >cols, entry) {
> + if (col->id == id)
> + return col;
> + }
> +
> + /* Should not happen in normal case */
> + panic("Invalid column id %u\n", id);

I'd rather omit the panic() here, return NULL and gracefully handle (if
possible) NULL returns in the callers.

> +}
> +
> +static void __ui_table_pos_update(struct ui_table *tbl)
> +{
> + struct ui_col *col;
> + uint32_t pos = tbl->x;
> +
> + list_for_each_entry(col, >cols, entry) {
> + col->pos  = pos;
> + pos  += col->len + tbl->col_pad;
> + }
> +}
> +
> +void ui_table_col_add(struct ui_table *tbl, uint32_t id, char *name, 
> uint32_t len)
> +{
> + struct ui_col *col = xzmalloc(sizeof(*col));
> +
> + col->id= id;
> + col->name  = name;
> + col->len   = len;
> + col->align = UI_ALIGN_LEFT;
> +
> + list_add_tail(>entry, >cols);
> +
> + __ui_table_pos_update(tbl);
> +}
> +
> +void ui_table_col_color_set(struct ui_table *tbl, int col_id, int color)
> +{
> + struct ui_col *col = ui_table_col_get(tbl, col_id);
> +
> + col->color = color;
> +}
> +
> +void ui_table_col_align_set(struct ui_table *tbl, int col_id, enum ui_align 
> align)
> +{
> + struct ui_col *col = ui_table_col_get(tbl, col_id);
> +
> + col->align = align;
> +}
> +
> +void ui_table_row_add(struct ui_table *tbl)
> +{
> + tbl->rows_y++;
> +}
> +
> +void ui_table_clear(struct ui_table *tbl)
> +{
> + tbl->rows_y = tbl->y;
> +}
> +
> +#define UI_ALIGN_COL(col) (((col)->align == UI_ALIGN_LEFT) ? "%-*.*s" : 
> "%*.*s")
> +
> +static void __ui_table_row_print(struct ui_table *tbl, struct ui_col *col,
> +  const char *str)
> +{
> + mvprintw(tbl->rows_y, col->pos, UI_ALIGN_COL(col), col->len, col->len, 
> str);
> + mvprintw(tbl->rows_y, col->pos + col->len, "%*s", tbl->col_pad, " ");
> +}
> +
> +void ui_table_row_print(struct ui_table *tbl, uint32_t col_id, const char 
> *str)
> +{
> + struct ui_col *col = ui_table_col_get(tbl, col_id);
> +
> + attron(col->color);
> + __ui_table_row_print(tbl, col, str);
> + attroff(col->color);
> +}
> +
> +void ui_table_header_color_set(struct ui_table *tbl, int color)
> +{
> + tbl->hdr_color = color;
> +}
> +
> +void ui_table_header_print(struct ui_table *tbl)
> +{
> + struct ui_col *col;
> + int max_width = tbl->width;
> + int width = 0;
> +
> + attron(tbl->hdr_color);
> +
> + mvprintw(tbl->y, tbl->x, "%-*.*s", max_width - tbl->x, max_width - 
> tbl->x, "");
> + mvprintw(tbl->y, tbl->x, "");
> +
> + list_for_each_entry(col, >cols, entry) {
> + __ui_table_row_print(tbl, col, col->name);
> + width += col->len + tbl->col_pad;
> + }
> + 

Trailing whitespace (tab) here.

> + mvprintw(tbl->y, width, "%*s", max_width - width, " ");
> + attroff(tbl->hdr_color);
> +}
> diff --git a/ui.h b/ui.h
> new file mode 100644
> index 000..02d1da2
> --- /dev/null
> +++ b/ui.h
> @@ -0,0 +1,53 @@
> +#ifndef UI_H
> +#define UI_H
> +
> +#include "list.h"
> +
> +#include 
> +#include 

[netsniff-ng] Re: [PATCH v2 00/11] flowtop: Layout change to 1-row view

[Tobias Klauser]

On 2016-04-17 at 19:31:23 +0200, Vadim Kochan  wrote:
> Changed flows list layout to look more a top-like output
> with header and in 1 line. When -s option is specified
> then layout changes to 2 lines view including with src peer
> info and dst under it on next line.
> 
> v2:
> 1) Add UI table widget with generic implementation for
>print list items in table style. Add new UI module with
>generic table API.
> 
> 2) Add Linux-like list API used from liburcu but with redefinitions
>to the Linux naming.
> 
> 3) Get rid of clear & refresh screen each time while flows printing.
> 
> Vadim Kochan (11):
>   geoip: Allow to get country 3-code
>   flowtop: Change flows layout to 1-row view
>   flowtop: Add display option to show src info
>   screen: Add helpers to easy use color by name
>   flowtop: Use new colors naming & helpers
>   list: Add re-defined double-linked list API from liburcu
>   ui: Implement UI table for flows printing
>   flowtop: Use new UI table API for draw flows list
>   ui: Print empty rows when clear table
>   flowtop: Get rid of clear() & refresh() calls
>   flowtop: Simplify flows refresh delay

Applied patches 1-5, waiting for the respin with the remaining ones.

Thanks a lot!

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 2/5] flowtop: Change flows layout to 1-row view

[Tobias Klauser]

On 2016-03-29 at 15:32:43 +0200, Vadim Kochan <vadi...@gmail.com> wrote:
> On Tue, Mar 29, 2016 at 4:23 PM, Tobias Klauser <tklau...@distanz.ch> wrote:
> > On 2016-03-23 at 22:00:44 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> >> Changed flows list layout to look more a top-like output
> >> with header and in 1 line. When -s option is specified
> >> then layout changes to 2 lines view including with src peer
> >> info and dst under it on next line.
> >>
> >> Also shortified flow state names to allocate less space.
> >>
> >> Removed presenter_get_port be cause ports are printed for both peers
> >> separately.
> >>
> >> The flow duration time is printed in very short form in one of the
> >> units:
> >> XXd - days
> >> XXh - hours
> >> XXm - minutes
> >> XXs - seconds
> >>
> >> the reason is that it is enough to have actually generic understanding
> >> about flow time in the biggest time unit.
> >>
> >> Signed-off-by: Vadim Kochan <vadi...@gmail.com>
> >> ---
> >>  flowtop.c | 405 
> >> ++
> >>  1 file changed, 194 insertions(+), 211 deletions(-)
> >>
> >> diff --git a/flowtop.c b/flowtop.c
> >> index 4c15c06..8201321 100644
> >> --- a/flowtop.c
> >> +++ b/flowtop.c
> >> @@ -62,6 +62,7 @@ struct flow_entry {
> >>   uint64_t pkts_dst, bytes_dst;
> >>   uint64_t timestamp_start, timestamp_stop;
> >>   char country_src[128], country_dst[128];
> >> + char country_code_src[4], country_code_dst[4];
> >>   char city_src[128], city_dst[128];
> >>   char rev_dns_src[256], rev_dns_dst[256];
> >>   char procname[256];
> >> @@ -166,11 +167,6 @@ static const char *copyright = "Please report bugs to 
> >> <netsniff-ng@googlegroups.
> >>   "This is free software: you are free to change and redistribute 
> >> it.\n"
> >>   "There is NO WARRANTY, to the extent permitted by law.";
> >>
> >> -static const char *const l3proto2str[AF_MAX] = {
> >> - [AF_INET]   = "ipv4",
> >> - [AF_INET6]  = "ipv6",
> >> -};
> >
> > Why remove L3 protocol information from the output? I consider this
> > quite useful. Could we somehow combine this with L4 Proto information in
> > a generic way?
> 
> I thought it will be easy to identify ipvX version by IPvX address format.

True, didn't think of it that way. I'm fine with omitting it in that case...

> >
> >> -
> >>  static const char *const l4proto2str[IPPROTO_MAX] = {
> >>   [IPPROTO_TCP]   = "tcp",
> >>   [IPPROTO_UDP]   = "udp",
> >> @@ -194,40 +190,40 @@ static const char *const l4proto2str[IPPROTO_MAX] = {
> >>  };
> >>
> >>  static const char *const tcp_state2str[TCP_CONNTRACK_MAX] = {
> >> - [TCP_CONNTRACK_NONE]= "NOSTATE",
> >> - [TCP_CONNTRACK_SYN_SENT]= "SYN_SENT",
> >> - [TCP_CONNTRACK_SYN_RECV]= "SYN_RECV",
> >> - [TCP_CONNTRACK_ESTABLISHED] = "ESTABLISHED",
> >> - [TCP_CONNTRACK_FIN_WAIT]= "FIN_WAIT",
> >> - [TCP_CONNTRACK_CLOSE_WAIT]  = "CLOSE_WAIT",
> >> - [TCP_CONNTRACK_LAST_ACK]= "LAST_ACK",
> >> - [TCP_CONNTRACK_TIME_WAIT]   = "TIME_WAIT",
> >> - [TCP_CONNTRACK_CLOSE]   = "CLOSE",
> >> - [TCP_CONNTRACK_SYN_SENT2]   = "SYN_SENT2",
> >> + [TCP_CONNTRACK_NONE]= "NO",
> >> + [TCP_CONNTRACK_SYN_SENT]= "SS",
> >> + [TCP_CONNTRACK_SYN_RECV]= "SR",
> >> + [TCP_CONNTRACK_ESTABLISHED] = "EST",
> >> + [TCP_CONNTRACK_FIN_WAIT]= "FWT",
> >> + [TCP_CONNTRACK_CLOSE_WAIT]  = "CWT",
> >> + [TCP_CONNTRACK_LAST_ACK]= "LAC",
> >> + [TCP_CONNTRACK_TIME_WAIT]   = "TWT",
> >> + [TCP_CONNTRACK_CLOSE]   = "CLO",
> >> + [TCP_CONNTRACK_SYN_SENT2]   = "SS2",
> >
> >
> > These abbreviations are no longer easy to grasp for the user without
> > looking at this struct 

[netsniff-ng] Re: [PATCH 2/5] flowtop: Change flows layout to 1-row view

[Tobias Klauser]

On 2016-03-23 at 22:00:44 +0100, Vadim Kochan  wrote:
> Changed flows list layout to look more a top-like output
> with header and in 1 line. When -s option is specified
> then layout changes to 2 lines view including with src peer
> info and dst under it on next line.
> 
> Also shortified flow state names to allocate less space.
> 
> Removed presenter_get_port be cause ports are printed for both peers
> separately.
> 
> The flow duration time is printed in very short form in one of the
> units:
> XXd - days
> XXh - hours
> XXm - minutes
> XXs - seconds
> 
> the reason is that it is enough to have actually generic understanding
> about flow time in the biggest time unit.
> 
> Signed-off-by: Vadim Kochan 
> ---
>  flowtop.c | 405 
> ++
>  1 file changed, 194 insertions(+), 211 deletions(-)
> 
> diff --git a/flowtop.c b/flowtop.c
> index 4c15c06..8201321 100644
> --- a/flowtop.c
> +++ b/flowtop.c
> @@ -62,6 +62,7 @@ struct flow_entry {
>   uint64_t pkts_dst, bytes_dst;
>   uint64_t timestamp_start, timestamp_stop;
>   char country_src[128], country_dst[128];
> + char country_code_src[4], country_code_dst[4];
>   char city_src[128], city_dst[128];
>   char rev_dns_src[256], rev_dns_dst[256];
>   char procname[256];
> @@ -166,11 +167,6 @@ static const char *copyright = "Please report bugs to 
>    "This is free software: you are free to change and redistribute it.\n"
>   "There is NO WARRANTY, to the extent permitted by law.";
>  
> -static const char *const l3proto2str[AF_MAX] = {
> - [AF_INET]   = "ipv4",
> - [AF_INET6]  = "ipv6",
> -};

Why remove L3 protocol information from the output? I consider this
quite useful. Could we somehow combine this with L4 Proto information in
a generic way?

> -
>  static const char *const l4proto2str[IPPROTO_MAX] = {
>   [IPPROTO_TCP]   = "tcp",
>   [IPPROTO_UDP]   = "udp",
> @@ -194,40 +190,40 @@ static const char *const l4proto2str[IPPROTO_MAX] = {
>  };
>  
>  static const char *const tcp_state2str[TCP_CONNTRACK_MAX] = {
> - [TCP_CONNTRACK_NONE]= "NOSTATE",
> - [TCP_CONNTRACK_SYN_SENT]= "SYN_SENT",
> - [TCP_CONNTRACK_SYN_RECV]= "SYN_RECV",
> - [TCP_CONNTRACK_ESTABLISHED] = "ESTABLISHED",
> - [TCP_CONNTRACK_FIN_WAIT]= "FIN_WAIT",
> - [TCP_CONNTRACK_CLOSE_WAIT]  = "CLOSE_WAIT",
> - [TCP_CONNTRACK_LAST_ACK]= "LAST_ACK",
> - [TCP_CONNTRACK_TIME_WAIT]   = "TIME_WAIT",
> - [TCP_CONNTRACK_CLOSE]   = "CLOSE",
> - [TCP_CONNTRACK_SYN_SENT2]   = "SYN_SENT2",
> + [TCP_CONNTRACK_NONE]= "NO",
> + [TCP_CONNTRACK_SYN_SENT]= "SS",
> + [TCP_CONNTRACK_SYN_RECV]= "SR",
> + [TCP_CONNTRACK_ESTABLISHED] = "EST",
> + [TCP_CONNTRACK_FIN_WAIT]= "FWT",
> + [TCP_CONNTRACK_CLOSE_WAIT]  = "CWT",
> + [TCP_CONNTRACK_LAST_ACK]= "LAC",
> + [TCP_CONNTRACK_TIME_WAIT]   = "TWT",
> + [TCP_CONNTRACK_CLOSE]   = "CLO",
> + [TCP_CONNTRACK_SYN_SENT2]   = "SS2",


These abbreviations are no longer easy to grasp for the user without
looking at this struct in the source. We should either keep the long
names (if possible) of at least add corresponding documentation about
the abbreviations to the manpage. Same goes for dccp_state2str and
sctp_state2str below.

>  };
>  
>  static const char *const dccp_state2str[DCCP_CONNTRACK_MAX] = {
> - [DCCP_CONNTRACK_NONE]   = "NOSTATE",
> - [DCCP_CONNTRACK_REQUEST]= "REQUEST",
> - [DCCP_CONNTRACK_RESPOND]= "RESPOND",
> - [DCCP_CONNTRACK_PARTOPEN]   = "PARTOPEN",
> - [DCCP_CONNTRACK_OPEN]   = "OPEN",
> - [DCCP_CONNTRACK_CLOSEREQ]   = "CLOSEREQ",
> - [DCCP_CONNTRACK_CLOSING]= "CLOSING",
> - [DCCP_CONNTRACK_TIMEWAIT]   = "TIMEWAIT",
> - [DCCP_CONNTRACK_IGNORE] = "IGNORE",
> - [DCCP_CONNTRACK_INVALID]= "INVALID",
> + [DCCP_CONNTRACK_NONE]   = "NO",
> + [DCCP_CONNTRACK_REQUEST]= "REQ",
> + [DCCP_CONNTRACK_RESPOND]= "RES",
> + [DCCP_CONNTRACK_PARTOPEN]   = "POP",
> + [DCCP_CONNTRACK_OPEN]   = "OPN",
> + [DCCP_CONNTRACK_CLOSEREQ]   = "CLQ",
> + [DCCP_CONNTRACK_CLOSING]= "CLN",
> + [DCCP_CONNTRACK_TIMEWAIT]   = "TWT",
> + [DCCP_CONNTRACK_IGNORE] = "IGN",
> + [DCCP_CONNTRACK_INVALID]= "INV",
>  };
>  
>  static const char *const sctp_state2str[SCTP_CONNTRACK_MAX] = {
> - [SCTP_CONNTRACK_NONE]   = "NOSTATE",
> - [SCTP_CONNTRACK_CLOSED] = "CLOSED",
> - [SCTP_CONNTRACK_COOKIE_WAIT]= "COOKIE_WAIT",
> - [SCTP_CONNTRACK_COOKIE_ECHOED]  = "COOKIE_ECHOED",
> - 

[netsniff-ng] [ANNOUNCE] netsniff-ng 0.6.1

[Tobias Klauser]

It is our pleasure to announce the release of netsniff-ng 0.6.1.

As always, the summary of changes and the short log of all changes since
v0.6.0 can be found below.

Thanks to everybody who contributed to this release:

  Vadim Kochan, Thomas Fleischmann, Reiner Herrmann, Erik Bengtsson,
  and Daniel Borkmann.

This release also means that the tree is again open for new features.

Happy packet sniffing!

---

netsniff-ng 0.6.1 (aisatsana) has been released to the public.

It can be fetched via Git:

   git clone git://github.com/netsniff-ng/netsniff-ng.git
   git checkout v0.6.1

Or via HTTP from one of our mirrors:

   http://pub.netsniff-ng.org/netsniff-ng/netsniff-ng-0.6.1.tar.gz
   http://mirror.distanz.ch/netsniff-ng/netsniff-ng-0.6.1.tar.gz
   http://github.com/netsniff-ng/netsniff-ng/archive/v0.6.1.tar.gz

The release can be verified via Git (see README):

   git tag -v v0.6.1

Major high-level changes since the last release (v0.6.0) are:

1) Newly added trafgen configuration language which allows to specify
   the packets in a more convenient format. See trafgen(8) for more
   details on the supported protocols and keywords. Contributed by Vadim
   Kochan.

2) Additional runtime commands for flowtop which allow to toggle/filter
   display of flows. From Vadim Kochan.

3) Command line options to pass macro definitions to trafgen and bpfc.
   From Vadim Kochan.

4) Made the build of all netsniff-ng tools reproducible (stable link
   order). From Reiner Herrmann.

5) Fix download of GeoIP databases so the files don't get corrupted.
   From Tobias Klauser.

Contributions since last release:

 64  Vadim Kochan
 49  Tobias Klauser
  1  Thomas Fleischmann
  1  Reiner Herrmann
  1  Erik Bengtsson
  1  Daniel Borkmann

Git changelog since last release:

Vadim Kochan (64):
  build: configure: Check for libnl-route
  flowtop: Add runtime command to show help window
  flowtop: Add runtime command to change rate units
  flowtop: Add runtime command to show only active flows
  str: Add converting cmdline args vector to str module
  trafgen: Allow to build packet from command line
  netsniff-ng: Allow to specify compiled BPF from stdin
  bpfc, trafgen: Do not close stdin when "-" is specified
  bpfc: man: Add example how to filter rtnetlink by attributes
  flowtop: Add header line with tool name & version
  netsniff-ng: nlmsg: Print not dissected attribute type number
  netsniff-ng: nlmsg: Print generic netlink ctrl family info
  netsniff-ng: nlmsg: Check message length before dissect rtnl
  bpfc: Do not panic if bpf file is not valid
  flowtop: Add runtime commands to filter flows by proto
  cpp: Add cpp.c module to invoke C preprocessor
  bpfc: Invoke C preprocessor from cpp.c module
  trafgen: Invoke C preprocessor from cpp.c module
  cpp: Use /tmp folder for output files
  trafgen: Make sure yyin is set before close it
  netsniff-ng: nlmsg: Print genl ops & mcast groups attributes
  proc: Add function to execute process with argv list
  cpp: Use new proc_exec function to invoke cpp
  cpp: Allow to pass additional cpp options
  str: Add helper to extend dynamically argv list
  bpfc: Add option to pass macro/define for C preprocessor
  trafgen: Added option to pass macro/define for C preprocessor
  flowtop: Show selected proto family
  flowtop: Indicate if 'active' flows mode is selected
  flowtop: Refresh flows if filter was changed while flows loading
  trafgen: Add option to specify packets sending rate
  flowtop: Use single function to update flow entry
  flowtop: Use one nfct handle for dump & refresh flows
  trafgen: Move gap feature into shaper logic
  trafgen: Simplify 'gap' option unit parsing
  trafgen: Simplify ring size unit parsing
  dissectors: arp: Print hardware & protocol addresses
  trafgen: Export set_fill func
  trafgen: Add helper to get current packet
  trafgen: Add basic protocol generation logic
  dev: Add function to get device hardware address
  trafgen: proto: Add function to set field from device MAC
  trafgen: l2: Add Ethernet protocol header generation
  str: Add str2mac helper function
  trafgen: parser: Add syntax to generate Ethernet header fields
  trafgen: proto: Add functon to fill field with device ipv4 address
  trafgen: l2: Add ARP header generation logic
  trafgen: parser: Add syntax to generate ARP header fields
  trafgen: l3: Add IPv4 header generation backend
  trafgen: parser: Add syntax for IPv4 protocol generation
  trafgen: l4: Add UDP header generation logic
  trafgen: parser: Add syntax to build UDP header
  trafgen: man: Add help for Ethernet, ARP, IPv4, UDP headers
  trafgen: proto: Simplify getting lower protocol after init
  trafgen: proto: Add set_next_proto callback to struct proto_h

[netsniff-ng] Re: flowtop: Flows visual separating

[Tobias Klauser]

On 2016-02-25 at 17:35:56 +0100, Vadim Kochan  wrote:
> On Sat, Feb 20, 2016 at 8:47 PM, Vadim Kochan  wrote:
> > On Sat, Feb 20, 2016 at 7:49 PM, Daniel Borkmann  
> > wrote:
> >> Hi Vadim,
> >>
> >> thanks for looking into this, appreciate it!
> >>
> >> On 02/20/2016 03:28 PM, Vadim Kochan wrote:
> >>>
> >>> On Sat, Feb 20, 2016 at 1:25 AM, Vadim Kochan  wrote:
> 
>  Hi,
> 
>  I tried to come up with visual separating of printed flows as currently
>  its not easy to identify separate flow entry, so I did some changes and
>  I am not sure if it looks good so I atached the screenshot.
> 
>  Regards,
> >>>
> >>>
> >>> I attached another version of odd & even flows entries style, here I
> >>> used cyan & white colors and it seem looks
> >>> better as here is no such contrast like in case with black & white
> >>> background colors (like in previous example),
> >>> also here 'country' color changed to magenta as it looks better on
> >>> white & cyan background colors.
> >>
> >>
> >> Not particularly a fan of these background colors, but I understand
> >> you'd like to improve usability on this. How about making flowtop
> >> look and navigation more like top or htop? Perhaps some of this info
> >> can be collapsed?

Fully agree with Daniel, I'm not a big fan of too much background color
(or even color in general) in TUI interfaces either. I'd certainly
prefer if you'd go for a top/htop like interface in that case.

> >>
> >> Thanks,
> >> Daniel
> >
> > Well, if to follow these *top-like tools then we need to print less
> > info. Curently we print:
> >
> > 1) process name
> > 2) flow state
> > 3) application proto name
> > 4) duration time
> > 5) src/dst hostname
> > 6) geo info
> > 7) pkts/bytes stats (counters & rate)

top/htop allow you to select the columns to display. We could define a
sensible set of default columns (or even add additional ones in case we
detect a wide enough window) and then let the user add/remove other
columns.

> >
> > We can have 2 modes for flows visualization:
> >
> > 1) Short mode (1 row per entry) (default):
> >  a) process name
> >  b) flow state (but with shortest names)
> >  c) application proto name
> >  d) src/dst info hostnames (or only dst with country if it feets)
> >  e) mixed stats
> >
> > 2) Extended mode, like in current implementation
> > (but maybe be changed to color scheme which I sent in previous 
> > example).

I don't think it's necessary to have 2 modes if we go for selectable
columns.

> > Also there might be hot-keys to
> > 1) expand 1-row entry into 3-row mode
> > 2) switch between 1- & 3- row mode for all entries.

In case the user's window isn't wide enough to hold all columns, this
would be a nice option to display additional information.

Cheers
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v2 0/4] trafgen: Add MPLS header creating

[Tobias Klauser]

On 2016-02-23 at 13:38:42 +0100, Vadim Kochan  wrote:
> Thanks!
> 
> So icmpv4 will appear in next version, I have patches but need to rebase them.

That'd be great if you could send them once the tree is open again, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] [ANNOUNCE] Tree closed for new features until v0.6.1 release

[Tobias Klauser]

As previously announced in the last release message [1], we slightly
changed our development model to do releases a bit more often and to
ditch the -rc releases.

[1] http://thread.gmane.org/gmane.linux.network.netsniff-ng/1258

In that vein, we'd like to close the tree for new features as of today,
which means we'll only take bug fixes and small, non-intrusive
fixes/cleanups we deem safe for inclusion in v0.6.1. The release is
planned in about two weeks time. Afterwards the tree is open again for
new features and more experimental changes.

We'd like to ask everybody who's interested in the netsniff-ng toolkit
to give the current git HEAD some good testing.

I'd especially like to point out the awesome new trafgen protocol
creation functions contributed by Vadim Kochan which make writing
trafgen config files for commonly used protocols a lot more convenient.
See the respective page section in trafgen(8) for the basic usage.

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

[netsniff-ng] Re: [PATCH 0/7] trafgen: Add VLAN header creating

[Tobias Klauser]

On 2016-02-02 at 17:27:26 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> On Tue, Feb 2, 2016 at 6:20 PM, Vadim Kochan <vadi...@gmail.com> wrote:
> > On Tue, Feb 2, 2016 at 5:54 PM, Tobias Klauser <tklau...@distanz.ch> wrote:
> >> On 2016-02-01 at 18:01:34 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> >>> Add 'vlan()' function for creating VLAN header 802.1q or 802.1ad.
> >>> There is a tricky change which changes struct proto_field.offset
> >>> uint16_t -> int16_t to allow negative values which is used in VLAN
> >>> protocol header by using -2 offset for TPID field which overlaps with
> >>> ether type field.
> >>>
> >>> Additionally series has changes for simplify setting correct upper 
> >>> protocol
> >>> id by lower layer by delegating this to the lower protocol. So upper 
> >>> protocol
> >>> specifies it's proto_id to the lower protocol which decides which field & 
> >>> value
> >>> to set.
> >>>
> >>> Vadim Kochan (7):
> >>>   trafgen: proto: Simplify getting lower protocol after init
> >>>   trafgen: proto: Add set_next_proto callback to struct proto_hdr
> >>>   trafgen: eth: Add setting next protocol id
> >>>   trafgen: ipv4: Add setting next protocol id
> >>>   trafgen: l2: Add VLAN header generation
> >>>   trafgen: parser: Add syntax for VLAN header creating
> >>>   trafgen: man: Add help for VLAN header function
> >>
> >> Series applied, thanks Vadim!
> >>
> >> Please note that I took out the VLAN ID setting as a pure number. I
> >> think it is a bit inconsistent with the rest of the functions and typing
> >> an additional 3 characters ('id=') shouldn't hurt too much and IMO also
> >> helps keep the configuration fields more readable. Hope that's OK with
> >> you.
> >
> > Well, I just was thinking that it would be good to have simple form of
> > adding VLAN header 'vlan(1)'
> > This form might relate to any small header where is some main numeric
> > parameter (e.g mpls).
> >
> > And really I think that 'vlan(100)' is enough readable and understandable.
> >
> > Regards,
> > Vadim Kochan
> 
> BTW, let me know if it would be helpful for you to have remote branch
> with changes on github too aside with patches via email ?

I for myself prefer to receive them by e-mail as this also allows Daniel
and other developers to comment on them and it is more consistent with
my workflow and I already have a bunch of scripts to integrate patches
into an own branch in my repo.

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] Replay pcap file on Xenomai kernel in real time

[Tobias Klauser]

On 2016-02-01 at 15:38:28 +0100, Umair Ali  wrote:
> Thanks a lot for the help offer. I can understand what you want to say. 
> 
> I need your feedback on the code which I have written. The flow of the code 
> is as follows
> - Reader the pcap file. the pcap file contained the captured Sampled Values 
> packets (IEC 61850 9-2 SV, Datalink layer lever)
> - The length of each packet is fixed which is 126 bytes and pcap only contain 
> SV packets.
> - The code below is opening pcap file and then mapping the file and closing 
> the pcap file
> - the Variable packet_index is used to point the start of every packet
> 
> It is very small code and it will few minutes to read. Please find the 
> attached file. I will appreciate your feedback and points of suggestions. 
> Thanks a lot once again and sorry for bugging you too much.

Sorry, but reviewing a random dump of code (that doesn't even compile)
goes beyond the scope of what I'd consider support/help for netsniff-ng.

As said, I'm happy to help with any problems you encounter specific to
the netsniff-ng toolkit or help you get patches integrated that make
netsniff-ng work better in your environment/application.

Good luck
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] Synchronize file creation between netsniff-ng processes possible?

[Tobias Klauser]

On 2016-01-28 at 22:04:45 +0100, e.bengts...@gmail.com  
wrote:
> Sounds good. Thanks!

Patch now applied, thanks a lot Erik!

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v3 00/16] trafgen: Add proto header generation

[Tobias Klauser]

On 2016-01-26 at 21:24:56 +0100, Vadim Kochan  wrote:
> Add new trafgen proto generation framework which allows to describe
> proto header fields and easy build the proto header by set/get proto
> header fields value.
> 
> Meanwhile implemented Ethernet, ARP, IPv4 & UDP proto headers generation,
> with fixed header size. Each proto has its own syntax rules
> to specify header field, but really looks similary:
> 
> { (=,, =) }
> 
> Proto statement might be combined with other packet funcs like:
> 
> { ip4(mf, proto=0x1), fill(0xff, 100) }
> 
> Each proto generates some default header so it is not possible to fill packet
> only with some set of header fields and rest - via fill(..) func.

I applied patches 1-11 from this series now. There were still a few
edges which I want to have a deeper look at, but any changes there can
be done in follow-up patches by myself.

As for patches 12-16: I didn't apply them because I'd like to see the
commit messages for the parser syntax parts (patches  a bit extended. I didn't 
do
this myself due to lack of time...

Please have a look at the amended commit messages for patches 8 and 11
I edited them quite heavily to include documentation for all supported
keywords, including default values. Please resend the patches for IPv4
and UDP syntax with similar commit messages.

For commit messages in general - and also for user visible messages and
documentation - please don't use abbreviations such as 'func' or 'proto'
but always spell out the full word. This makes it much easier to read
IMO.

As for the manpage part, I'll respond with detailed review comments
there, but in general it looks very good.

Thanks a lot!

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] Synchronize file creation between netsniff-ng processes possible?

[Tobias Klauser]

On 2016-01-28 at 13:17:30 +0100, e.bengts...@gmail.com <e.bengts...@gmail.com> 
wrote:
> 
> 
> Den onsdag 27 januari 2016 kl. 18:02:23 UTC+1 skrev e.ben...@gmail.com:
> >
> >
> >
> > Den onsdag 27 januari 2016 kl. 16:17:46 UTC+1 skrev Tobias Klauser:
> >>
> >> Hi again 
> >>
> >> On 2016-01-27 at 16:10:30 +0100, Tobias Klauser <tkla...@distanz.ch> 
> >> wrote: 
> >> > On 2016-01-27 at 14:40:55 +0100, Erik Bengtsson <e.ben...@gmail.com> 
> >> wrote: 
> >> > > By "start time" I mean file creation time. It is totally possible to 
> >> post 
> >> > > process all log files and synchronize them using pcap timestamps, as 
> >> you 
> >> > > suggested, but I'm afraid that it will be less effective for us since 
> >> there 
> >> > > will be a huge amount of data to move around and process. 
> >> > 
> >> > Ah ok, I see. Thanks for clarifying. 
> >> > 
> >> > In that case, I'm afraid there currently is no method to synchronize 
> >> the file 
> >> > creation among multiple instances of netsniff-ng. As Daniel suggested, 
> >> > timerfd might be an option to implement a feature along these lines. If 
> >> > you want, feel free to have a look into it - patches are gladly 
> >> accepted 
> >> > :) 
> >>
> >> Something which I completely forgot about... 
> >>
> >> There might be an option (though a bit curde) to solve this using the 
> >> permature rotation caused by SIGHUP. You could set up a separate task 
> >> simultaneously sending a SIGHUP every minute to your netsniff-ng 
> >> processes. See commit 46289df6bc8f573bc01be4fb4aa93343ecc6d50a 
> >> ("netsniff-ng: Rotate pcap files prematurely on SIGHUP") for details. 
> >>
> >> Tobias 
> >>
> >
> > That sounds really interesting! :-)
> >
> > I ended up using signal USR2 since i didn't want to change how SIGHUP was 
> > used. When USR2 is received, the current time is saved and used when naming 
> > the next file (which is created when the next packet is received).
> >
> > A patch is included if you want to have a look.
> >
> > / Erik
> >  
> >
> 
> I've continued working on this a bit and have a solution that seems to be 
> working. The patch is included if someone wants to have a look.

Nice, thanks a lot. I think we don't even need to have a command line
option for this but could just make it the default behavior to record
the timestamp of the sighup in the filename. The file creation time will
still reflect the actual time of when the first packet arrived.

I'll adjust the patch accordingly and commit it with your Signed-off-by,
if that's ok with you.

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 0/4] trafgen: Add IPv4 and UDP protocol generation

[Tobias Klauser]

On 2016-01-28 at 23:06:23 +0100, Vadim Kochan  wrote:
> Reworded commit message of 12-14 patches from series:
> 
> "[PATCH v3 00/16] trafgen: Add proto header generation"
> 
> 1) Added parameters & default values description.
> 2) Functionality was not changed.

Perfect, thanks a lot! Series now applied. I also took the manpage patch
from your previous series and I'll directly fold in my few minor changes.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] Replay pcap file on Xenomai kernel in real time

[Tobias Klauser]

Hi Ali

On 2016-01-27 at 13:01:55 +0100, Umair Ali  wrote:
> Hello there,
> 
> I am working on the project of replaying the pcap files in the real time over 
> the network. For this purpose I am using the real time Linux kernel 'Xenomai 
> v 3.0.1'. My idea is to write a code in C which will read the pcap file 
> packet by packet and then send the packet as raw Ethernet packet over the 
> real time interface. When the pcap libraries are used on the xenomai then the 
> process of reading pcap files does not behave in real time any more. Moreover 
> the xenomai uses the mmap for reading the files in real time. I have tried to 
> use the mmap technique to read pcap file but it is not perfect and works for 
> small files. I have read the netsniff.ng tool uses the same mmap technique to 
> read the pcap file for replaying the pcap file. My question is that how mmap 
> is used in netsniff-ng tool to read the pcap file packet by packet. Can you 
> give me the C code as an example to read the pcap file using mmap packet by 
> packet. I shall be highly thankful.

Have a look at pcap_mm.c, the mmap base pcap read/write functions are
defined there.

Hope that helps
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] Replay pcap file on Xenomai kernel in real time

[Tobias Klauser]

On 2016-01-27 at 15:15:01 +0100, Umair Ali  wrote:
> Hi Tobias,
> 
> Thanks for the quick reply. I have read pcap_mm.c file but cannot understand 
> the flow of the code. Can you explain me the flow that once the pcap file is 
> open using mmap then how it is further processed to extract packet by packet 
> and replay. Is it possible with netsniff-ng to send packet every 5micro secs 
> or less. 

The mmap pcap functions (like the scatter-gather and the standard file
i/o functions) are wired up in struct pcap_file_ops *pcap_ops and then
used by the respective functions in netsniff-ng.cx according to the pcap
access method is set in ctx->pcap (PCAP_OPS_MM in case of mmap).
read_pcap in netsniff-ng.c is probably most interesting to you.

HTH
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] Synchronize file creation between netsniff-ng processes possible?

[Tobias Klauser]

Hi again

On 2016-01-27 at 16:10:30 +0100, Tobias Klauser <tklau...@distanz.ch> wrote:
> On 2016-01-27 at 14:40:55 +0100, Erik Bengtsson <e.bengts...@gmail.com> wrote:
> > By "start time" I mean file creation time. It is totally possible to post
> > process all log files and synchronize them using pcap timestamps, as you
> > suggested, but I'm afraid that it will be less effective for us since there
> > will be a huge amount of data to move around and process.
> 
> Ah ok, I see. Thanks for clarifying.
> 
> In that case, I'm afraid there currently is no method to synchronize the file
> creation among multiple instances of netsniff-ng. As Daniel suggested,
> timerfd might be an option to implement a feature along these lines. If
> you want, feel free to have a look into it - patches are gladly accepted
> :)

Something which I completely forgot about...

There might be an option (though a bit curde) to solve this using the
permature rotation caused by SIGHUP. You could set up a separate task
simultaneously sending a SIGHUP every minute to your netsniff-ng
processes. See commit 46289df6bc8f573bc01be4fb4aa93343ecc6d50a
("netsniff-ng: Rotate pcap files prematurely on SIGHUP") for details.

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v2 11/16] trafgen: parser: Add syntax to generate ARP header fields

[Tobias Klauser]

On 2016-01-26 at 09:47:32 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> On Tue, Jan 26, 2016 at 10:25 AM, Tobias Klauser <tklau...@distanz.ch> wrote:
> > On 2016-01-26 at 00:11:53 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> >> Add syntax to generate ARP header fields:
> >>
> >> { arp(op=req, sip=1.1.1.1, smac=11:22:33:44:55:66) }
> >> { arp() }
> >>
> >> Signed-off-by: Vadim Kochan <vadi...@gmail.com>
> >> ---
> >>
> >>  %%
> >>
> >> @@ -107,7 +109,16 @@ mac  
> >> ({mac_hex}:{mac_hex}:{mac_hex}:{mac_hex}:{mac_hex}:{mac_hex})
> >>  "saddr"|"sa" { return K_SADDR; }
> >>  "prot"[o]?   { return K_PROT; }
> >>
> >
> > Shouldn't we allow to specify htype, ptype, hlen and plen as well (as a
> > user might want to set non-conforming values)?
> >
> Well meanwhile it was easier to implement for me the Ethernet-IPv4
> form of ARP (which is more generic and
> used by masezahn too if I am not mistaken), and it looks a little
> tricky to allow full-flexible ARP header crafting.
> I'd like to add such ability on later work, if I will not dig into
> mac80211 headers ... :-)

Ok, I see :-) But htpye/ptype should still be possible without having
dynamic header length, no?

> >> +"sha"|"smac" { return K_SHA; }
> >> +"spa"|"sip"  { return K_SPA; }
> >> +"tha"|"tmac" { return K_THA; }
> >> +"tpa"|"tip"  { return K_TPA; }
> >> +"req"{ return K_REQ; }
> >
> > Please add "request" as well.
> >
> Sure.
> 
> >>   ;
> >>
> >> +arp_proto
> >> + : arp '(' arp_param_list ')' { }
> >> + ;
> >> +
> >> +arp_param_list
> >> + : { }
> >> + | arp_field { }
> >> + | arp_field delimiter arp_param_list { }
> >> + ;
> >> +
> >> +arp_field
> >> + : K_OPER  skip_white '=' skip_white K_REQ
> >> + { proto_field_set_be16(hdr, ARP_OPER, ARPOP_REQUEST); }
> >> + | K_OPER  skip_white '=' skip_white K_RESP
> >> + { proto_field_set_be16(hdr, ARP_OPER, ARPOP_REPLY); }
> >
> > Would be nice to allow numeric values here as well (again, to be able to
> > specify values not conforming to the standard).
> >
> 
> Right I will change it to the form:
> 
> arp(request, ...)
> arp(reply, ...)
> arp(op=)

Looks good.

> Not sure if the following is also will be needed considering above's forms:
> 
> arp(op=request)

I'd keep it in for consistency reasons.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v2 15/16] trafgen: parser: Add syntax to build UDP header

[Tobias Klauser]

On 2016-01-26 at 00:11:57 +0100, Vadim Kochan  wrote:
> Added trafgen syntax to set UDP header fields:
> 
> { udp(sport=111, dport=222) }
> 
> Signed-off-by: Vadim Kochan 
> ---
>  trafgen_lexer.l  |  4 
>  trafgen_parser.y | 29 +
>  2 files changed, 33 insertions(+)
> 
> diff --git a/trafgen_lexer.l b/trafgen_lexer.l
> index 26876b4..98afc91 100644
> --- a/trafgen_lexer.l
> +++ b/trafgen_lexer.l
> @@ -131,9 +131,13 @@ ip_addr  ([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)
>  "df" { return K_DF; }
>  "mf" { return K_MF; }
>  
> +"sp"|"sport" { return K_SPORT; }
> +"dp"|"dport" { return K_DPORT; }

What about the length and checksum fields?

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v2 03/16] trafgen: Add basic proto generation logic

[Tobias Klauser]

On 2016-01-26 at 00:11:45 +0100, Vadim Kochan  wrote:
[...]
> +void proto_header_init(enum proto_id pid)
> +{
> + struct proto_hdr *hdr = proto_header_by_id(pid);
> + struct proto_hdr *new;
> +
> + if (headers_count >= PROTO_MAX_LAYERS)
> + panic("Too much proto headers\n");
> +
> + new = malloc(sizeof(*new));

Use xmalloc here, as we would otherwise dereference NULL.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 00/13] trafgen: Add proto header generation

[Tobias Klauser]

On 2016-01-25 at 10:06:04 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> On Mon, Jan 25, 2016 at 09:56:37AM +0100, Tobias Klauser wrote:
> > On 2016-01-21 at 00:19:48 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> > > Add new trafgen proto generation framework which allows to describe
> > > proto header fields and easy build the proto header by set/get proto
> > > header fields value.
> > 
> > This is great, thanks a lot for doing this! I only had the chance to
> > have a quick look at the series and couldn't find any major problems,
> > except for one thing: Please add a patch for trafgen.8, adding a section
> > which shortly describes the keywords, supported protocols, default
> > values for fields not specified etc. Having the user dig through git
> > commit messages or parser grammars to figure out how to use these
> > features is not very nice :)
> > 
> > Once you add that I think we can safely apply the series and fix any
> > remaining issues in follow-up patches. I'll also reply to some of the
> > patches with some minor comments which you might want to consider for v2
> > along with the changes you already announced.
> > 
> > Thanks!
> 
> BTW, I reworked to make possible to specify headers in any order and
> multiple times (which was not possible in previous version), so it
> allows to make such constructions like:
> 
> { ip(), ip(proto=0x1) }
> 
> which builds ip-in-ip header (including Ethernet). And now user
> responsible to specify the order of headers, but lower layers still will
> be added automatically if they were not specified by user.
> 
> Regarding man changes, well I did not include it because I am not good
> in English so to do not block this series in case of English issues I
> decided to work on it separately, but OK - I will try to document it.

I'm not a native English speaker/writer either, so no worries :) We can
still wordsmith on the documentation later on, or based on your patch.
The important part to me is that the keywords and the rules for protocol
default values are documented somewhere.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 10/13] trafgen: l2: Add ARP header generation logic

[Tobias Klauser]

On 2016-01-21 at 00:19:58 +0100, Vadim Kochan  wrote:
> Add ARP proto header fields generation via src mac, src ip,
> dst mac, dst ip & operaion.
> 
> By default Ethernet proto will be initialized, and ARP probe
> request is filled.
> 
> Signed-off-by: Vadim Kochan 
> ---
>  trafgen_l2.c | 45 +
>  trafgen_l2.h | 12 
>  2 files changed, 57 insertions(+)
> 
> diff --git a/trafgen_l2.c b/trafgen_l2.c
> index 5d245b8..adee113 100644
> --- a/trafgen_l2.c
> +++ b/trafgen_l2.c
> @@ -3,10 +3,15 @@
>   * Subject to the GPL, version 2.
>   */
>  
> +#include 
> +#include 
> +
>  #include "built_in.h"
>  #include "trafgen_l2.h"
>  #include "trafgen_proto.h"
>  
> +#define ETH_BCAST { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }
> +
>  struct proto_field eth_fields[] = {
>   { .id = ETH_DST_ADDR, .len = 6, },
>   { .id = ETH_SRC_ADDR, .len = 6, .offset = 6 },
> @@ -25,7 +30,47 @@ static struct proto_gen eth_prot = {
>   .header_init= eth_header_init,
>  };
>  
> +static struct proto_field arp_fields[] = {
> + { .id = ARP_HTYPE, .len = 2 },
> + { .id = ARP_PTYPE, .len = 2, .offset = 2 },
> + { .id = ARP_HLEN,  .len = 1, .offset = 4 },
> + { .id = ARP_PLEN,  .len = 1, .offset = 5 },
> + { .id = ARP_OPER,  .len = 2, .offset = 6 },
> + { .id = ARP_SHA,   .len = 6, .offset = 8 },
> + { .id = ARP_SPA,   .len = 4, .offset = 14 },
> + { .id = ARP_THA,   .len = 6, .offset = 18 },
> + { .id = ARP_TPA,   .len = 4, .offset = 24 },
> +};
> +
> +static void arp_header_init(struct proto_gen *prot)
> +{
> + uint8_t mac[6] = ETH_BCAST;
> +
> + proto_header_init(PROTO_ETH);
> +
> + proto_field_set_default_bytes(PROTO_ETH, ETH_DST_ADDR, mac);
> + proto_field_set_default_be16(PROTO_ETH, ETH_PROTO_ID, ETH_P_ARP);
> +
> + proto_fields_add(prot->id, arp_fields, array_size(arp_fields));
> +
> + /* Generate probe request by default */
> + proto_field_set_default_be16(prot->id, ARP_HTYPE, ARPHRD_ETHER);
> + proto_field_set_default_be16(prot->id, ARP_PTYPE, ETH_P_IP);
> + proto_field_set_default_u8(prot->id, ARP_HLEN, 6);
> + proto_field_set_default_u8(prot->id, ARP_PLEN, 4);
> + proto_field_set_default_be16(prot->id, ARP_OPER, ARPOP_REQUEST);
> +proto_field_set_default_dev_mac(prot->id, ARP_SHA);

Please use tab to indent here as well.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 13/13] trafgen: parser: Add syntax for IPv4 proto

[Tobias Klauser]

On 2016-01-21 at 00:20:01 +0100, Vadim Kochan  wrote:
> Add syntax to specify IPv4 header fields:
> 
> { ip(df, mf, frag=100, prot=0x1, ecn=2, dscp=20) }
> 
> Signed-off-by: Vadim Kochan 
> ---
>  trafgen_lexer.l  | 15 +++
>  trafgen_parser.y | 51 +++
>  2 files changed, 66 insertions(+)
> 
> diff --git a/trafgen_lexer.l b/trafgen_lexer.l
> index 9bbd982..b9bcd10 100644
> --- a/trafgen_lexer.l
> +++ b/trafgen_lexer.l
> @@ -117,8 +117,23 @@ ip_addr  ([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)
>  "resp"|"reply"   { return F_RESP; }
>  "op" { return F_OPER; }
>  
> +"ihl"{ return F_IHL; }
> +"ver"{ return F_VER; }

Maybe add "version" here as well?

> +"ttl"{ return F_TTL; }
> +"dscp"   { return F_DSCP; }
> +"ecn"{ return F_ECN; }
> +"tos"{ return F_TOS; }
> +"len"{ return F_LEN; }

"length"?

> +"id" { return F_ID; }
> +"flags"  { return F_FLAGS; }
> +"frag"   { return F_FRAG; }
> +"csum"   { return F_CSUM; }
> +"df" { return F_DF; }
> +"mf" { return F_MF; }
> +
>  "eth"{ return P_ETH; }
>  "arp"{ return P_ARP; }
> +"ip" { return P_IP4; }

I think this should be "ip4" or "ipv4" (or both), in order to be
consistent with a possible future extension to support IPv6.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 0/2] trafgen: Small changes for unit parsing (gap, ring size)

[Tobias Klauser]

On 2016-01-14 at 00:22:39 +0100, Vadim Kochan  wrote:
> Small simplification of unit parsing for gap & ring size option by using
> strtoul for setting start of unit name instead of checking it char by char.
> 
> Vadim Kochan (2):
>   trafgen: Simplify 'gap' option unit parsing
>   trafgen: Simplify ring size unit parsing

Series applied, thanks Vadim.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] trafgen: Move gap feature into shaper logic

[Tobias Klauser]

On 2016-01-07 at 07:34:46 +0100, Vadim Kochan  wrote:
> Move gap feature into rate shaper, as these features
> means the same - delay the packet sending.
> 
> Signed-off-by: Vadim Kochan 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 1/2] flowtop: Use one func to update flow entry

[Tobias Klauser]

On 2016-01-05 at 20:42:39 +0100, Vadim Kochan  wrote:
> Seems there is no need to have 2 separate handlers
> for the flow updating, so use one which was used
> for flow refreshing. Significant change is that new entry
> will be not added if it was not found in the list, but such
> case should not happen.

The sentence above sounds rather strange by itself. It would be nice to
explain _why_ this is the case (i.e the NFCT_T_NEW event).

Otherwise the patch looks good to me.

Applied with an updated description.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 2/2] flowtop: Use one nfct handle for dump & refresh flows

[Tobias Klauser]

On 2016-01-05 at 20:42:40 +0100, Vadim Kochan  wrote:
> Simplify dump & flows refreshing via one nfct handle, which is enough.
> 
> Signed-off-by: Vadim Kochan 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v2] trafgen: Add option to specify packets sending rate

[Tobias Klauser]

On 2015-12-28 at 10:19:12 +0100, Vadim Kochan  wrote:
> On Fri, Dec 25, 2015 at 03:19:59AM +0200, Vadim Kochan wrote:
> > On Wed, Dec 23, 2015 at 10:58:32PM +0200, Vadim Kochan wrote:
> > > On Wed, Dec 23, 2015 at 10:31:23PM +0200, Vadim Kochan wrote:
> > > > Added -b,--rate option in units of:
> > > > 
> > > > pps/B/kB/MB/kBit/Mbit/Gbit/KiB/MiB/GiB
> > > > 
> > > > to specify rate at which packets will be sent.
> > > > Similary to -t,--gap option the packets will be sent
> > > > in slow mode with 1 CPU.
> > > > 
> > > > Tested with ifpps.
> > > > 
> > > > Signed-off-by: Vadim Kochan 

[...]

> Sorry, may be I confused you, but I think this patch seems OK, you can
> ignore my message that it does not work for mtu > 1500 as I was
> performing wrong tests where rate was much less than packet len. So you
> can review it.

Ok, patch applied now. 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 0/3] flowtop: Misc updates: filter state, refresh flag reset

[Tobias Klauser]

On 2015-12-16 at 21:12:06 +0100, Vadim Kochan  wrote:
> There are just few different changes like:
> 1) Show family in filter status bar
> 2) Show if 'Active' flows mode is selected in filter status bar
> 3) Reset do_refresh flag immideately if it is enabled to make able
>refresh flows again if this flag was changed while refreshing.
> 
> Vadim Kochan (3):
>   flowtop: Show selected proto family
>   flowtop: Indicate if 'active' flows mode is selected
>   flowtop: Refresh flows if filter was changed while flows loading

Series applied, thanks Vadim!

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v4 1/6] proc: Add function to execute process with argv list

[Tobias Klauser]

On 2015-12-15 at 22:09:10 +0100, Vadim Kochan  wrote:
> Add proc_exec function which executes given process with
> argv list via fork + execvp.
> 
> It allows to replace 'system' call approach which is used
> for invoking cpp and securely extend it with additional options
> like -D.
> 
> Signed-off-by: Vadim Kochan 

Series applied with some minor modifications (added const qualifiers
where applicable, changed some data types).

Thanks a lot, this is nice work!

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v4 1/6] proc: Add function to execute process with argv list

[Tobias Klauser]

On 2015-12-16 at 10:05:33 +0100, vkochan <vadi...@gmail.com> wrote:
> Hi,
> 
> On Wed, Dec 16, 2015 at 09:34:28AM +0100, Tobias Klauser wrote:
> > On 2015-12-15 at 22:09:10 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> > > Add proc_exec function which executes given process with
> > > argv list via fork + execvp.
> > > 
> > > It allows to replace 'system' call approach which is used
> > > for invoking cpp and securely extend it with additional options
> > > like -D.
> > > 
> > > Signed-off-by: Vadim Kochan <vadi...@gmail.com>
> > > ---
> > 
> > For future patch series where you send multiple version, please add a
> > small changelog here (below the ---) of what changed between the
> > versions. Otherwise it's more cumbersome to determine whether something
> > has changed in the patch at all and needs a new review. This means
> > review time will be larger for the maintainers :(
> 
> Usually I do this but I was thinking that maintainer will review the
> whole submitted changes, and may be this changelog might be useless ...
> actually I assumed that maintainer will do not trust the changelog but
> will go review each line again.

Not necessarily. I want to avoid duplicating work, so I usually only
to a full review on patches which were actually changed and check
whether review comments have been addressed. Having a changelog helps to
quickly identify whether the patch author thinks they have adressed all
review comments with this.

> > For larger patch series, please also send along a cover letter (git
> > format-patch --cover-letter) where you give a short summary of the
> > overall idea of the series. In this case, adding the version changelog
> > to the cover letter is preferred.
> 
> Really I was doing that but I observed that you responded only to each
> patch so I decided that may be you skip the cover letter.

Sure, I only respond to the patches themselves, but the cover letter is
still useful. Please note that me not replying to the cover letter does not
imply I didn't read it :), I'd reply to the cover letter in case I
applied the series as a whole or if I had change requests to the overall
idea of the series.

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 1/4] netsniff-ng: nlmsg: Resolve genl family name

[Tobias Klauser]

On 2015-11-30 at 01:05:04 +0100, Vadim Kochan  wrote:
> Print name of resolved genl family name by type

This patch does quite a bit more than the description says (i.e. the
init/uninit hooks). Please be a bit more verbose in your patch
descriptions.

> Signed-off-by: Vadim Kochan 
> ---
>  dissector_netlink.c |  3 ++
>  proto.h | 15 ++
>  proto_nlmsg.c   | 82 
> +
>  protos.h|  2 +-
>  4 files changed, 96 insertions(+), 6 deletions(-)
> 
> diff --git a/dissector_netlink.c b/dissector_netlink.c
> index 2b23a99..b4de112 100644
> --- a/dissector_netlink.c
> +++ b/dissector_netlink.c
> @@ -19,10 +19,13 @@ static inline void dissector_init_exit(int type)
>  
>  void dissector_init_netlink(int fnttype)
>  {
> + proto_ops_init(_ops);
> +
>   dissector_init_entry(fnttype);
>   dissector_init_exit(fnttype);
>  }
>  
>  void dissector_cleanup_netlink(void)
>  {
> + proto_ops_uninit(_ops);
>  }
> diff --git a/proto.h b/proto.h
> index 0cc1fd8..03a07e2 100644
> --- a/proto.h
> +++ b/proto.h
> @@ -10,6 +10,7 @@
>  
>  #include 
>  #include 
> +#include 

What is this needed for?

>  
>  #include "tprintf.h"
>  
> @@ -20,6 +21,8 @@ struct protocol {
>   const unsigned int key;
>   void (*print_full)(struct pkt_buff *pkt);
>   void (*print_less)(struct pkt_buff *pkt);
> + void (*init)(void);
> + void (*uninit)(void);

I don't think the very specific case of dissecting genl family messages
deserves the introduction of these hooks. How about just doing the init
work the first time the genl stuff is actually used?

Sorry for the brevity, I currently have a very limited bandwidth to
review patches...

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v2] bpfc, trafgen: Allow to pass C preprocessor macro/define

[Tobias Klauser]

On 2015-12-01 at 23:04:18 +0100, Vadim Kochan  wrote:
> Add -D option for bpfc & trafgen to make possible pass -Dkey=value
> to C preprocessor. Characters like .?*()[]-^|`!#$&<>;\ are quoted
> to do not trick with shell's special symbols (e.g. process spawning),
> \ is ignored only if it goes before " - to make possible pass escaped
> text for trafgen's conf file.

Please split this up into at least 4 patches to make review easier:

1) string list helper
1) helpers to create/check/... argument list (cpp module)
2) trafgen integration
3) bpfc integration

I'm also still not a big fan of the shell escaping solution. This adds a
lot of string handling code which needs to be reviewed _very_ carefully.
If somehow possible I'd like to avoid this alltogether. Could we maybe
get rid of the call to system() alltogether and instead use fork() +
execvp() + wait() and pass the definitions args as we got them from
getopt? You'd need to use the "-o" option to cpp instead of the input
redirection, but that should be fine...

A few minor remarks below, but not a complete review (due to limited
time at the moment).

> Signed-off-by: Vadim Kochan 
> ---
>  bpf_parser.y |  6 ++--
>  bpfc.8   |  6 
>  bpfc.c   | 16 --
>  cpp.c| 97 
> +---
>  cpp.h|  2 +-
>  str.c| 10 ++
>  str.h|  1 +
>  trafgen.8|  7 
>  trafgen.c| 22 +
>  trafgen_conf.h   |  3 +-
>  trafgen_parser.y |  5 +--
>  11 files changed, 154 insertions(+), 21 deletions(-)
> 
> diff --git a/bpf_parser.y b/bpf_parser.y
> index 003c031..28e8d11 100644
> --- a/bpf_parser.y
> +++ b/bpf_parser.y
> @@ -28,7 +28,7 @@
>  #include "cpp.h"
>  
>  int compile_filter(char *file, int verbose, int bypass, int format,
> -bool invoke_cpp);
> +bool invoke_cpp, char **cpp_defs);

c
>  
>  static int curr_instr = 0;
>  
> @@ -735,7 +735,7 @@ static void pretty_printer(const struct sock_fprog *prog, 
> int format)
>  }
>  
>  int compile_filter(char *file, int verbose, int bypass, int format,
> -bool invoke_cpp)
> +bool invoke_cpp, char **cpp_defs)
>  {
>   int i;
>   struct sock_fprog res;
> @@ -745,7 +745,7 @@ int compile_filter(char *file, int verbose, int bypass, 
> int format,
>   memset(tmp_file, 0, sizeof(tmp_file));
>  
>   if (invoke_cpp) {
> - ret = cpp_exec(file, tmp_file, sizeof(tmp_file));
> + ret = cpp_exec(file, tmp_file, sizeof(tmp_file), cpp_defs);
>   if (ret) {
>   fprintf(stderr, "Failed to invoke C preprocessor!\n");
>   goto exit;
> diff --git a/bpfc.8 b/bpfc.8
> index 8a99e2e..eeb8356 100644
> --- a/bpfc.8
> +++ b/bpfc.8
> @@ -65,6 +65,12 @@ Pass the bpf program through the C preprocessor before 
> reading it in
>  bpfc. This allows #define and #include directives (e.g. to include
>  definitions from system headers) to be used in the bpf program.
>  .PP
> +.SS -D, --define
> +Add macro/define for C preprocessor to use it within bpf file. You may need 
> the shell's
> +quoting syntax to protect characters such as spaces that have a meaning in 
> the shell syntax.
> +By default the following characters .?*()[]-^|`!$&<>;\\ are escaped 
> automatically when
> +calling C preprocessor.

Please explicitly mention that this flag is only useful together with
-p/--cpp, same goes for the trafgen manpage.

> +.PP
>  .SS -f , --format 
>  Specify a different output format than the default that is netsniff-ng
>  compatible. The  specifier can be: C, netsniff-ng, xt_bpf, tcpdump.
> diff --git a/bpfc.c b/bpfc.c
> index d360cf5..fb7a9e5 100644
> --- a/bpfc.c
> +++ b/bpfc.c
> @@ -17,12 +17,14 @@
>  #include "die.h"
>  #include "bpf.h"
>  #include "config.h"
> +#include "str.h"
>  
> -static const char *short_options = "vhi:Vdbf:p";
> +static const char *short_options = "vhi:Vdbf:pD:";
>  static const struct option long_options[] = {
>   {"input",   required_argument,  NULL, 'i'},
>   {"format",  required_argument,  NULL, 'f'},
>   {"cpp", no_argument,NULL, 'p'},
> + {"define",  required_argument,  NULL, 'D'},
>   {"verbose", no_argument,NULL, 'V'},
>   {"bypass",  no_argument,NULL, 'b'},
>   {"dump",no_argument,NULL, 'd'},
> @@ -39,7 +41,7 @@ static const char *copyright = "Please report bugs to 
>    "There is NO WARRANTY, to the extent permitted by law.";
>  
>  extern int compile_filter(char *file, int verbose, int bypass, int format,
> -   bool invoke_cpp);
> +   bool invoke_cpp, char **cpp_defs);
>  
>  static void __noreturn help(void)
>  {
> @@ -49,6 +51,7 @@ static void __noreturn help(void)
>"Options:\n"
>

[netsniff-ng] Re: [PATCH 2/5] cpp: Allow to pass cpp arguments

[Tobias Klauser]

On 2015-11-29 at 13:42:43 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> On Wed, Nov 25, 2015 at 10:31:28AM +0100, Tobias Klauser wrote:
> > On 2015-11-25 at 00:51:48 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> > > Extend cpp_exec func to pass cpp arguments
> > > 
> > > Signed-off-by: Vadim Kochan <vadi...@gmail.com>
> > > ---
> > >  bpf_parser.y | 2 +-
> > >  cpp.c| 6 +++---
> > >  cpp.h| 2 +-
> > >  trafgen_parser.y | 2 +-
> > >  4 files changed, 6 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/bpf_parser.y b/bpf_parser.y
> > > index 8aed9dc..db6a007 100644
> > > --- a/bpf_parser.y
> > > +++ b/bpf_parser.y
> > > @@ -745,7 +745,7 @@ int compile_filter(char *file, int verbose, int 
> > > bypass, int format,
> > >   memset(tmp_file, 0, sizeof(tmp_file));
> > >  
> > >   if (invoke_cpp) {
> > > - ret = cpp_exec(file, tmp_file, sizeof(tmp_file));
> > > + ret = cpp_exec(file, tmp_file, sizeof(tmp_file), NULL);
> > >   if (ret) {
> > >   fprintf(stderr, "Failed to invoke C preprocessor!\n");
> > >   goto exit;
> > > diff --git a/cpp.c b/cpp.c
> > > index 6734eac..99c4c33 100644
> > > --- a/cpp.c
> > > +++ b/cpp.c
> > > @@ -4,7 +4,7 @@
> > >  #include "str.h"
> > >  #include "xmalloc.h"
> > >  
> > > -int cpp_exec(char *in_file, char *out_file, size_t out_len)
> > > +int cpp_exec(char *in_file, char *out_file, size_t out_len, char *args)
> > >  {
> > >   char *tmp = xstrdup(in_file);
> > >   char cmd[256], *base;
> > > @@ -13,8 +13,8 @@ int cpp_exec(char *in_file, char *out_file, size_t 
> > > out_len)
> > >   base = basename(tmp);
> > >  
> > >   slprintf(out_file, out_len, "/tmp/.tmp-%u-%s", rand(), base);
> > > - slprintf(cmd, sizeof(cmd), "cpp -I" ETCDIRE_STRING " %s > %s",
> > > -  in_file, out_file);
> > > + slprintf(cmd, sizeof(cmd), "cpp -I" ETCDIRE_STRING " %s %s > %s",
> > > +  args ? args : "", in_file, out_file);
> > 
> > By crafting an appropriate string, a user might be able to inject
> > additional, potentially dangerous commands here using 'args'. I'd
> > suggest to pass the args similar to (int argc, char **argv) to cpp_exec
> > and then do the prefixing with -D in cpp_exec.
> > 
> > Also you should check the contents of the passed definitions carefully
> > (i.e. they only contain valid macro definitions).
> 
> What about automatically escape such characters like '&><"\;#$ by prepending 
> '\' ?

Sure, as long as the resulting string is a valid macro definition which
cannot be used to spawn processes I'm fine with that too.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] netsniff-ng: nlmsg: Print genl ops & mcast groups attributes

[Tobias Klauser]

On 2015-11-27 at 08:58:39 +0100, Vadim Kochan  wrote:
> Dump Generic netlink ops & mcast groups nested attributes.
> 
> Signed-off-by: Vadim Kochan 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v2] flowtop: Add runtime commands to filter flows by proto

[Tobias Klauser]

On 2015-11-22 at 10:39:06 +0100, Vadim Kochan  wrote:
> Add U/T/I/D/S runtime commands (same like for command line)
> to filter flows by UDP/TCP/ICMP/DCCP/SCTP proto.
> 
> Signed-off-by: Vadim Kochan 

Applied now, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 4/4] cpp: Use /tmp folder for output files

[Tobias Klauser]

On 2015-11-19 at 05:07:49 +0100, Vadim Kochan  wrote:
> There might be a case when input file is located
> in read-only directory and cpp fails when it tries to
> create output file there, so use /tmp folder for that
> as usually it should be writeable for any user.
> 
> Signed-off-by: Vadim Kochan 

LGTM, please adjust to the requested changes in patch 1/4 and resend.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 2/4] bpfc: Invoke C preprocessor from cpp.c module

[Tobias Klauser]

On 2015-11-19 at 05:07:47 +0100, Vadim Kochan  wrote:
> Use cpp_process func from cpp.c module to invoke
> C preprocessor.
> 
> Signed-off-by: Vadim Kochan 

LGTM, please resend along with adjustments v2 of patch 1/4.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 2/2] flowtop: Add runtime commands to show TCP/UDP/DCCP/ICMP/SCTP

[Tobias Klauser]

On 2015-11-12 at 07:54:19 +0100, Vadim Kochan  wrote:
> Now it is possible toggle display TCP/UDP/DCCP/ICMP/SCTP protos
> by the same char keys as short command line options - T/U/D/I/S.
> 
> Signed-off-by: Vadim Kochan 
> ---
>  flowtop.c | 69 
> +++
>  1 file changed, 65 insertions(+), 4 deletions(-)
> 
> diff --git a/flowtop.c b/flowtop.c
> index 4c6f383..b6d3a08 100644
> --- a/flowtop.c
> +++ b/flowtop.c
> @@ -104,6 +104,14 @@ enum flow_direction {
>  #define INCLUDE_ICMP (1 << 5)
>  #define INCLUDE_SCTP (1 << 6)
>  
> +#define TOGGLE_FLAG(what, flag) \
> +do { \
> + if (what & flag)\
> + what &= ~flag;  \
> + else\
> + what |= flag;   \
> +} while (0)
> +
>  struct sysctl_params_ctx {
>   int nfct_acct;
>   int nfct_tstamp;
> @@ -114,6 +122,7 @@ enum rate_units {
>   RATE_BYTES
>  };
>  
> +static volatile bool do_reload_flows;
>  static volatile bool is_flow_collecting;
>  static volatile sig_atomic_t sigint = 0;
>  static int what = INCLUDE_IPV4 | INCLUDE_IPV6 | INCLUDE_TCP;
> @@ -462,7 +471,6 @@ static void flow_list_destroy(struct flow_list *fl)
>   }
>  
>   synchronize_rcu();
> - spinlock_destroy(>lock);
>  }
>  
>  static int walk_process(unsigned int pid, struct flow_entry *n)
> @@ -1186,8 +1194,14 @@ static void draw_help(WINDOW *screen)
>   mvaddnstr(row + 9, col + 2, "Display Settings", -1);
>   attroff(A_BOLD | A_UNDERLINE);
>  
> - mvaddnstr(row + 11, col + 3, "b Toggle rate units 
> (bits/bytes)", -1);
> - mvaddnstr(row + 12, col + 3, "a Toggle display of active 
> flows (rate > 0) only", -1);
> + mvaddnstr(row + 11, col + 3, "b Toggle rate units (bits/bytes)", 
> -1);
> + mvaddnstr(row + 12, col + 3, "a Toggle display of active flows 
> (rate > 0) only", -1);
> +
> + mvaddnstr(row + 14, col + 3, "T Toggle display TCP flows", -1);
> + mvaddnstr(row + 15, col + 3, "U Toggle display UDP flows", -1);
> + mvaddnstr(row + 16, col + 3, "D Toggle display DCCP flows", -1);
> + mvaddnstr(row + 17, col + 3, "I Toggle display ICMP flows", -1);
> + mvaddnstr(row + 18, col + 3, "S Toggle display SCTP flows", -1);
>  }
>  
>  static void draw_header(WINDOW *screen)
> @@ -1217,6 +1231,27 @@ static void draw_footer(WINDOW *screen)
>   attroff(A_STANDOUT);
>  }
>  
> +static void show_option_toggle(int opt)
> +{
> + switch (opt) {
> + case 'T':
> + TOGGLE_FLAG(what, INCLUDE_TCP);
> + break;
> + case 'U':
> + TOGGLE_FLAG(what, INCLUDE_UDP);
> + break;
> + case 'D':
> + TOGGLE_FLAG(what, INCLUDE_DCCP);
> + break;
> + case 'I':
> + TOGGLE_FLAG(what, INCLUDE_ICMP);
> + break;
> + case 'S':
> + TOGGLE_FLAG(what, INCLUDE_SCTP);
> + break;
> + }
> +}
> +
>  static void presenter(void)
>  {
>   int time_sleep_us = 20;
> @@ -1238,11 +1273,13 @@ static void presenter(void)
>   rcu_register_thread();
>   while (!sigint) {
>   bool redraw_flows = true;
> + int ch;
>  
>   curs_set(0);
>   getmaxyx(screen, rows, cols);
>  
> - switch (getch()) {
> + ch = getch();
> + switch (ch) {
>   case 'q':
>   sigint = 1;
>   break;
> @@ -1274,6 +1311,18 @@ static void presenter(void)
>   wclear(screen);
>   clear();
>   break;
> + case 'T':
> + case 'U':
> + case 'D':
> + case 'I':
> + case 'S':
> + if (is_flow_collecting)
> + break;

In this case we will silently discard the user input, which is not very
nice. Do you see any reasonable way to avoid that?

> +
> + show_option_toggle(ch);
> +
> + do_reload_flows = true;
> + break;
>   default:
>   fflush(stdin);
>   redraw_flows = false;
> @@ -1606,11 +1655,21 @@ static void *collector(void *null __maybe_unused)
>  
>   rcu_register_thread();
>  
> +reload:
> + if (do_reload_flows)
> + collector_create_filter(ct_event);
> +
> + do_reload_flows = false;
>   collector_dump_flows();
>  
>   while (!sigint) {
>   int status;
>  
> + if (do_reload_flows) {
> + flow_list_destroy(_list);
> + goto reload;

Ugh, I don't like jumping out of the loop here, even if it saves some
code duplication. But in that case I'd rather opt for duplicating the 4
LoC above.

Otherwise looks good to me.

> + }
> +
>   

[netsniff-ng] Re: [PATCH] bpfc: Do not panic if bpf file is not valid

[Tobias Klauser]

On 2015-11-15 at 22:16:37 +0100, Vadim Kochan  wrote:
> If bpf file is not valid then cpp generated file is not
> deleted because panic() func is invoked.
> 
> Signed-off-by: Vadim Kochan 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] netsniff-ng: Allow to specify compiled BPF from stdin

[Tobias Klauser]

On 2015-11-10 at 09:18:18 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> On Tue, Nov 10, 2015 at 09:06:17AM +0100, Tobias Klauser wrote:
> > On 2015-11-10 at 07:29:12 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> > > Allow read compiled BPF instructions from stdin by via '-f -' option.
> > > 
> > > Signed-off-by: Vadim Kochan <vadi...@gmail.com>
> > > ---
> > >  bpf.c | 6 +-
> > >  netsniff-ng.8 | 5 +++--
> > >  netsniff-ng.c | 2 +-
> > >  3 files changed, 9 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/bpf.c b/bpf.c
> > > index 2d769ec..15d804d 100644
> > > --- a/bpf.c
> > > +++ b/bpf.c
> > > @@ -720,7 +720,11 @@ void bpf_parse_rules(char *rulefile, struct 
> > > sock_fprog *bpf, uint32_t link_type)
> > >   return;
> > >   }
> > >  
> > > - fp = fopen(rulefile, "r");
> > > + if (!strcmp(rulefile, "-"))
> > > + fp = stdin;
> > 
> > Shouldn't we avoid fclose()ing stdin in this case later on in the
> > function?
> > 
> > Otherwise the patch looks good to me.
> 
> BTW, in bpf_parser.y stdin is closed too ...

Indeed, thanks for pointing out. Care to send a patch for this as well?

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH v2] netsniff-ng: Allow to specify compiled BPF from stdin

[Tobias Klauser]

On 2015-11-10 at 09:28:08 +0100, Vadim Kochan  wrote:
> Allow read compiled BPF instructions from stdin by via '-f -' option.
> 
> Signed-off-by: Vadim Kochan 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] bpfc, trafgen: Do not close stdin when "-" is specified

[Tobias Klauser]

On 2015-11-10 at 09:53:33 +0100, Vadim Kochan  wrote:
> Do not perform fclose for stdin fd.
> 
> Signed-off-by: Vadim Kochan 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 2/2] trafgen: Allow to build packet from command line

[Tobias Klauser]

On 2015-11-07 at 15:55:16 +0100, Vadim Kochan  wrote:
> Craft packet direct from command line with same syntax as for conf file.
> It might be as first step to extend current syntax with specific proto fields.
> 
> Signed-off-by: Vadim Kochan 

Nice work, thanks. Now applied.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 1/2] str: Add converting cmdline args vector to str

[Tobias Klauser]

On 2015-11-07 at 15:55:15 +0100, Vadim Kochan  wrote:
> Move piece of code which converts cmdline args vector to string
> from netsniff-ng.c to str.c as function.
> 
> Signed-off-by: Vadim Kochan 

Applied with slightly changed function/argument names. 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 2/3] flowtop: Add runtime command to change rate units

[Tobias Klauser]

On 2015-11-06 at 23:23:25 +0100, Vadim Kochan  wrote:
> Add interactive command 'b' to change rate units to show.
> 
> Signed-off-by: Vadim Kochan 

Applied, thanks Vadim!

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 1/3] flowtop: Add runtime command to show help window

[Tobias Klauser]

On 2015-11-06 at 23:23:24 +0100, Vadim Kochan  wrote:
[...]
> +static void draw_help(WINDOW *screen)
> +{
> + int col = 0;
> + int row = 0;
> + int i;
> +
> + mvaddch(row, col, ACS_ULCORNER);
> + mvaddch(rows - row - 2, col, ACS_LLCORNER);
> +
> + mvaddch(row, cols - 1, ACS_URCORNER);
> + mvaddch(rows - row - 2, cols - col - 1, ACS_LRCORNER);
> +
> + for (i = 1; i < rows - row - 2; i++) {
> + mvaddch(row + i, 0, ACS_VLINE);
> + mvaddch(row + i, cols - col - 1, ACS_VLINE);
> + }
> + for (i = 1; i < cols - col - 1; i++) {
> + mvaddch(0, col + i, ACS_HLINE);
> + mvaddch(rows - row - 2, col + i, ACS_HLINE);
> + }
> +
> + attron(A_BOLD);
> + mvaddnstr(row, cols / 2 - 2, "| Help |", -1);
> +
> + attron(A_UNDERLINE);
> + mvaddnstr(row + 2, col + 2, "Navigation", -1);
> + attroff(A_BOLD | A_UNDERLINE);
> +
> + mvaddnstr(row + 4, col + 3, "Up, u, k  Move up", -1);
> + mvaddnstr(row + 5, col + 3, "Down, d, jMove down", -1);
> + mvaddnstr(row + 6, col + 3, "ESC   Close window", -1);
> + mvaddnstr(row + 7, col + 3, "? Show 'Help'", -1);

I changed this to "Toggle help window", see below.

> + mvaddnstr(row + 8, col + 3, "q, Ctrl+C Quit", -1);
> +}
[...]
> @@ -1192,22 +1239,46 @@ static void presenter(void)
>   if (skip_lines > SCROLL_MAX)
>   skip_lines = SCROLL_MAX;
>   break;
> + case '?':
> + if (show_help)
> + show_help = false;
> + else
> + show_help = true;
> +
> + wclear(screen);
> + clear();
> + break;
> + case 27: /* ESC */
> + show_help = false;
> + wclear(screen);
> + clear();
> + break;

I don't think we need an extra command for this. Using '?' to toggle the
help window should be sufficient. I removed the command, adjusted the
help text and applied the patch.

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] flowtop: Redraw screen in 1s if no key was pressed

[Tobias Klauser]

On 2015-11-05 at 23:07:45 +0100, Vadim Kochan  wrote:
> Seems like screen is updating too frequently which
> may block some terminals, so lets do it once in 1s
> but only if no key was pressed.
> 
> Signed-off-by: Vadim Kochan 

Applied, thanks Vadim.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] curvetun: Move copyright text to separate variable

[Tobias Klauser]

On 2015-11-05 at 16:38:51 +0100, Vadim Kochan  wrote:
> Use copyright text from one place when print it in version or help output.
> 
> Signed-off-by: Vadim Kochan 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] lookup: Do not panic if conf file does not exist

[Tobias Klauser]

On 2015-11-05 at 16:49:29 +0100, Vadim Kochan  wrote:
> It is not necessary to do not allow run application if
> there is no conf file for port resolving, but instead print
> message to stderr.

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] Re: [PATCH] build: Check for libnl-route

[Tobias Klauser]

On 2015-11-06 at 16:53:02 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> On Fri, Nov 06, 2015 at 04:36:08PM +0100, Tobias Klauser wrote:
> > On 2015-11-06 at 15:46:16 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> > > libnl-route is used in netsniff-ng tool for dump nlmsg flags.
> > > 
> > > Signed-off-by: Vadim Kochan <vadi...@gmail.com>
> > 
> > Good catch! Applied, thanks.
> 
> I think it would be good to make (if it is possible) to make libnl
> dependency optionally. As I remember is is used mostly for creating mon
> interfaces, so may be it is better to do just panic if the config for
> libnl is not defined by configure script, so it will be needed to wrap
> libnl callers with #ifdef's where panic will be invoked.

Besides the nlmsg dissector it's used for rfmon support, i.e. this would
mean making making --rfraw in netsniff-ng and trafgen compile time
dependent. I would much prefer to avoid this, unless there's a strong
reason for it.

Do you see a use case for an netsniff-ng without libnl to justify this
change? Given also, that all major distributions I know of provide libnl
and it has a rather small footprint...

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] Re: [PATCH] build: Check for libnl-route

[Tobias Klauser]

On 2015-11-06 at 17:06:55 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> On Fri, Nov 06, 2015 at 05:05:38PM +0100, Tobias Klauser wrote:
> > On 2015-11-06 at 16:53:02 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> > > On Fri, Nov 06, 2015 at 04:36:08PM +0100, Tobias Klauser wrote:
> > > > On 2015-11-06 at 15:46:16 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> > > > > libnl-route is used in netsniff-ng tool for dump nlmsg flags.
> > > > > 
> > > > > Signed-off-by: Vadim Kochan <vadi...@gmail.com>
> > > > 
> > > > Good catch! Applied, thanks.
> > > 
> > > I think it would be good to make (if it is possible) to make libnl
> > > dependency optionally. As I remember is is used mostly for creating mon
> > > interfaces, so may be it is better to do just panic if the config for
> > > libnl is not defined by configure script, so it will be needed to wrap
> > > libnl callers with #ifdef's where panic will be invoked.
> > 
> > Besides the nlmsg dissector it's used for rfmon support, i.e. this would
> > mean making making --rfraw in netsniff-ng and trafgen compile time
> > dependent. I would much prefer to avoid this, unless there's a strong
> > reason for it.
> > 
> > Do you see a use case for an netsniff-ng without libnl to justify this
> > change? Given also, that all major distributions I know of provide libnl
> > and it has a rather small footprint...
> 
> I am just thinking in a way to make a less dependencies if to use
> trafgen/netsniff-ng on the system where there is not needed to install libnl 
> ...
> Or may be provide some defines which may turn on/off code which depends
> on such libs.

Ok, I see. If you see a way to make this work in a way which is not too
intrusive (#ifdef hell etc.), I'll gladly take a patch.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] flowtop: Calc flow rate more carefully

[Tobias Klauser]

On 2015-11-04 at 20:42:15 +0100, Vadim Kochan  wrote:
> Make rate calculation more carefully by checking previous & current
> bytes/pkts counter.
> 
> Do calculation only if update time passed >= 1s.
> 
> Signed-off-by: Vadim Kochan 

Applied, thank you Vadim!

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: netsniff-ng: pcap to json

[Tobias Klauser]

On 2015-11-05 at 12:28:29 +0100, Vadim Kochan  wrote:
> What do you think if it is a good idea to convert pcap to json by netsniff-ng 
> ?
> I mean to add such feature ...

What would be the use case for this? Is there a kind of standardized
representation for packets in JSON?

In any case, I think it goes a bit beyond the scope of netsniff-ng,
since we would then also need to support capturing to JSON which - as I
suspect - will be quite some overhead due to the conversion to a
text-based representation which in turn slows down capturing.

Thus I think it should rather be made into a separate tool.

Daniel, what do you think?

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: About next release date

[Tobias Klauser]

Hi Vadim

On 2015-10-30 at 09:59:46 +0100, Vadim Kochan  wrote:
> I'd like to know when you plan to do the next release, actually
> I have some plans regarding flowtop which I think might be good to have in
> the next release like sorting by rate & probably by received/sent traffic, and
> probably some simple filtering at least by process.

Ah nice!

> Let me know if you have some ideas.
> 
> Anyway it would be good to have some notification before release is happened:)

Sure, will do. Actually, I'm planing to do a release since some time
already, but unfortunately other work has gotten in the way :(

I want to get back to a more regular release schedule and want to drop
the -rc releases. Instead, we'll release a new version every 2-3 months
(depending on the work that went in, of course).

If nothing gets in the way, I'd like to get out a 0.5.10 (or should we
make it 0.6.9? ;) release with the current feature set some time next
week.

The features you suggest for flowtop would then probably be material for
the release after this one (depending on the patch size and when you
plan to submit them).

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] flowtop: Add command-line option for show rate in bits

[Tobias Klauser]

On 2015-10-28 at 06:39:26 +0100, Vadim Kochan  wrote:
> Add -b,--bits command line option for show rate in bits.
> 
> Signed-off-by: Vadim Kochan 

Applied, thanks Vadim.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] all: Change reporting bugs email

[Tobias Klauser]

On 2015-10-28 at 08:38:15 +0100, Vadim Kochan  wrote:
> Replace b...@netsniff-ng.com to netsniff-ng@googlegroups.com
> which is used in REPORTING-BUGS file.
> 
> Signed-off-by: Vadim Kochan 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 2/5] flowtop: Allow disable hostname lookup

[Tobias Klauser]

On 2015-10-27 at 01:00:48 +0100, Vadim Kochan  wrote:
> Added option -n,--no-dns which disables hostname lookup.
> 
> Signed-off-by: Vadim Kochan 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 1/5] flowtop: Fix src hostname showed with garbage

[Tobias Klauser]

On 2015-10-27 at 10:59:10 +0100, vkochan <vadi...@gmail.com> wrote:
> On Tue, Oct 27, 2015 at 10:51:26AM +0100, Tobias Klauser wrote:
> > On 2015-10-27 at 01:00:47 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> > > Use strlcpy for copy resolved src/dst hostname.
> > > 
> > > Signed-off-by: Vadim Kochan <vadi...@gmail.com>
> > > ---
> > >  flowtop.c | 9 +++--
> > >  1 file changed, 3 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/flowtop.c b/flowtop.c
> > > index cfe76d5..50064bb 100644
> > > --- a/flowtop.c
> > > +++ b/flowtop.c
> > > @@ -730,12 +730,9 @@ static void flow_entry_get_extended_revdns(struct 
> > > flow_entry *n,
> > >   getnameinfo(sa, sa_len, SELFLD(dir, rev_dns_src, rev_dns_dst),
> > >   sizeof(n->rev_dns_src), NULL, 0, NI_NUMERICHOST);
> > >  
> > > - if (hent) {
> > > - memset(n->rev_dns_dst, 0, sizeof(n->rev_dns_dst));
> > > - memcpy(SELFLD(dir, rev_dns_src, rev_dns_dst),
> > > -hent->h_name, min(sizeof(n->rev_dns_src),
> > > -  strlen(hent->h_name)));
> > > - }
> > > + if (hent)
> > > + strlcpy(SELFLD(dir, rev_dns_src, rev_dns_dst), hent->h_name,
> > > + min(sizeof(n->rev_dns_src), strlen(hent->h_name) + 1));
> > 
> > Just use sizeof(n->rev_dns_src) as the size argument here instead of the
> > min(), strlcpy will take care of the rest.
> 
> OK, yeah, sorry for such stupid mistakes ...

No problem. I'll apply your patch with the change squashed in so you
don't need to respin the patch.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 4/5] flowtop: Show rate in bits by default but in bytes optionaly

[Tobias Klauser]

On 2015-10-27 at 01:00:50 +0100, Vadim Kochan  wrote:
> Show rate in bits, but allow to show in bytes by -B,--rate-bytes option.

I think it should be the other way around, i.e. the default mode shows the
rate in bytes and you can switch to bits via command-line option. In my
experience bits/s are mostly used in the context of lower level protocols
(e.g. Ethernet), while higher level protocols (such as the ones handled
by flowtop) use bytes/s.

Care to respin accordingly?

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 4/5] flowtop: Lookup process by dst port too

[Tobias Klauser]

On 2015-10-26 at 14:16:09 +0100, vkochan <vadi...@gmail.com> wrote:
> On Mon, Oct 26, 2015 at 01:38:41PM +0100, Tobias Klauser wrote:
> > On 2015-10-24 at 16:38:10 +0200, Vadim Kochan <vadi...@gmail.com> wrote:
> > > From: Vadim Kochan <vadi...@gmail.com>
> > > 
> > > Perform lookup inode by dst port too if remote traffic represented as
> > > src flow, so in case if lookup by src port failed then choose
> > > inode matched by dst port.
> > > 
> > > Signed-off-by: Vadim Kochan <vadi...@gmail.com>
> > > ---
> > >  flowtop.c | 37 +
> > >  1 file changed, 21 insertions(+), 16 deletions(-)
> > > 
> > > diff --git a/flowtop.c b/flowtop.c
> > > index 6aa0a6e..f36e8fe 100644
> > > --- a/flowtop.c
> > > +++ b/flowtop.c
> > > @@ -503,40 +503,50 @@ static void walk_processes(struct flow_entry *n)
> > >   closedir(dir);
> > >  }
> > >  
> > > -static int get_port_inode(uint16_t port, int proto, bool is_ip6)
> > > +static void flow_entry_find_process(struct flow_entry *n)
> > >  {
> > > - int ret = -ENOENT;
> > > + int src_inode = 0, dst_inode = 0;
> > >   char path[128], buff[1024];
> > >   FILE *proc;
> > >  
> > >   memset(path, 0, sizeof(path));
> > >   snprintf(path, sizeof(path), "/proc/net/%s%s",
> > > -  l4proto2str[proto], is_ip6 ? "6" : "");
> > > +  l4proto2str[n->l4_proto], n->l3_proto == AF_INET6 ? "6" : "");
> > >  
> > >   proc = fopen(path, "r");
> > >   if (!proc)
> > > - return -EIO;
> > > + return;
> > >  
> > > + /* Here we try to find process's socket inode by src port, at the same
> > > +  * time we try to do it by dst port too which will be choosen in case
> > > +  * if src port inode will be not found, this is needed in case if the
> > > +  * 1st flow's packet will be originated from the remote server so then
> > > +  * local host will be represented as dst flow.
> > > +  */
> > >   memset(buff, 0, sizeof(buff));
> > > -
> > >   while (fgets(buff, sizeof(buff), proc) != NULL) {
> > > - int inode = 0;
> > >   unsigned int lport = 0;
> > > + int inode = 0;
> > >  
> > >   buff[sizeof(buff) - 1] = 0;
> > >   if (sscanf(buff, "%*u: %*X:%X %*X:%*X %*X %*X:%*X %*X:%*X "
> > >  "%*X %*u %*u %u", , ) == 2) {
> > > - if ((uint16_t) lport == port) {
> > > - ret = inode;
> > > +
> > > + if ((uint16_t) lport == n->port_src) {
> > > + src_inode = inode;
> > >   break;
> > > + } else if ((uint16_t) lport == n->port_dst) {
> > > + dst_inode = inode;
> > 
> > Shouldn't we break here as well?
>  Let me think again on this, I did not put break here because there might be 
> a case that
>  port_dst might be matched to some other local port earlier than port_src and 
> then the wrong inode might found.
>  But now I see that it can't be solved by this patch too ... Seems this
>  is not easy to find locally generated flow (except by matching with
>  local interface addresses) because in case if 1st flow's packet will be
>  generated from remote, then local traffic will be identified as dst flow ...

Ah, I see.

Before you think too much about it: I'd prefer to keep the lookup logic
rather simple. So if you can't figure out the inode reliably without
keeping a lot of internal state or querying a lot of information (i.e.
easily), I'd suggest we just keep the logic as it is and leave dst port
lookup aside.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 3/5] flowtop: Fix src hostname with garbage

[Tobias Klauser]

On 2015-10-26 at 15:07:31 +0100, vkochan <vadi...@gmail.com> wrote:
> On Mon, Oct 26, 2015 at 01:33:11PM +0100, Tobias Klauser wrote:
> > On 2015-10-24 at 16:38:09 +0200, Vadim Kochan <vadi...@gmail.com> wrote:
> > > From: Vadim Kochan <vadi...@gmail.com>
> > > 
> > > Add missing reset for src hostname buffer.
> > > 
> > > Signed-off-by: Vadim Kochan <vadi...@gmail.com>
> > > ---
> > >  flowtop.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/flowtop.c b/flowtop.c
> > > index c58ae0a..6aa0a6e 100644
> > > --- a/flowtop.c
> > > +++ b/flowtop.c
> > > @@ -723,7 +723,9 @@ static void flow_entry_get_extended_revdns(struct 
> > > flow_entry *n,
> > >   sizeof(n->rev_dns_src), NULL, 0, NI_NUMERICHOST);
> > >  
> > >   if (hent) {
> > > - memset(n->rev_dns_dst, 0, sizeof(n->rev_dns_dst));
> > > + memset(SELFLD(dir, rev_dns_src, rev_dns_dst),
> > > +0, sizeof(n->rev_dns_src));
> > > +
> > 
> > While the change is certainly correct, I think the memset() isn't really
> > necessary here. Wouldn't it be better to just use strlcpy here?
> 
> I suppose you meant strncpy ?

No, I meant strlcpy from str.c which is what we use in all netsniff-ng
tools (except mausezahn) for string copy.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 5/5] flowtop: Add option for flow refresh interval

[Tobias Klauser]

On 2015-10-24 at 16:38:11 +0200, Vadim Kochan  wrote:
> From: Vadim Kochan 
> 
> Add new -t,--interval option to specify flow refresh time in seconds.
> 
> Signed-off-by: Vadim Kochan 

Applied, 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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 3/5] flowtop: Fix src hostname with garbage

[Tobias Klauser]

On 2015-10-24 at 16:38:09 +0200, Vadim Kochan  wrote:
> From: Vadim Kochan 
> 
> Add missing reset for src hostname buffer.
> 
> Signed-off-by: Vadim Kochan 
> ---
>  flowtop.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/flowtop.c b/flowtop.c
> index c58ae0a..6aa0a6e 100644
> --- a/flowtop.c
> +++ b/flowtop.c
> @@ -723,7 +723,9 @@ static void flow_entry_get_extended_revdns(struct 
> flow_entry *n,
>   sizeof(n->rev_dns_src), NULL, 0, NI_NUMERICHOST);
>  
>   if (hent) {
> - memset(n->rev_dns_dst, 0, sizeof(n->rev_dns_dst));
> + memset(SELFLD(dir, rev_dns_src, rev_dns_dst),
> +0, sizeof(n->rev_dns_src));
> +

While the change is certainly correct, I think the memset() isn't really
necessary here. Wouldn't it be better to just use strlcpy here?

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [RFC] flowtop: Show flow rate of bytes & pkts

[Tobias Klauser]

On 2015-10-20 at 19:46:07 +0200, Vadim Kochan  wrote:
> Calculate & print the rate of src/dst bytes & pkts.
> Also changed refresh flows time to 1s so the rate
> info will be not disappeared very soon.

Looks good to me in general and I like the idea. A few minor comments
below.

> Signed-off-by: Vadim Kochan 
> ---
>  flowtop.c | 90 
> ---
>  1 file changed, 80 insertions(+), 10 deletions(-)
> 
> diff --git a/flowtop.c b/flowtop.c
> index 9df4bdb..c348e33 100644
> --- a/flowtop.c
> +++ b/flowtop.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -64,6 +65,11 @@ struct flow_entry {
>   unsigned int procnum;
>   bool is_visible;
>   struct nf_conntrack *ct;
> + struct timeval last_update;
> + double rate_bytes_src;
> + double rate_bytes_dst;
> + double rate_pkts_src;
> + double rate_pkts_dst;
>  };
>  
>  struct flow_list {
> @@ -197,6 +203,18 @@ static const struct nfct_filter_ipv6 filter_ipv6 = {
>   .mask = { 0x, 0x, 0x, 0x },
>  };
>  
> +static double time_after_us(struct timeval *tv)

No need to return a double here. Make this an int64_t...

> +{
> + struct timeval now;
> +
> + gettimeofday(, NULL);
> +
> + now.tv_sec  -= tv->tv_sec;
> + now.tv_usec -= tv->tv_usec;
> +
> + return (now.tv_sec * 100.0 + now.tv_usec);
> +}
> +
>  static void signal_handler(int number)
>  {
>   switch (number) {
> @@ -252,6 +270,28 @@ static void version(void)
>   die();
>  }
>  
> +static void flow_entry_update_time(struct flow_entry *n)
> +{
> + gettimeofday(>last_update, NULL);
> +}
> +
> +static void flow_entry_calc_rate(struct flow_entry *n, struct nf_conntrack 
> *ct)
> +{
> + uint64_t bytes_src = nfct_get_attr_u64(ct, ATTR_ORIG_COUNTER_BYTES);
> + uint64_t bytes_dst = nfct_get_attr_u64(ct, ATTR_REPL_COUNTER_BYTES);
> + uint64_t pkts_src  = nfct_get_attr_u64(ct, ATTR_ORIG_COUNTER_PACKETS);
> + uint64_t pkts_dst  = nfct_get_attr_u64(ct, ATTR_REPL_COUNTER_PACKETS);
> + double sec = time_after_us(>last_update) / 100.0;

...here it will become a double anyhow.

> +
> + if (sec <= 0)
> + return;
> +
> + n->rate_bytes_src = (bytes_src - n->bytes_src) / sec;
> + n->rate_bytes_dst = (bytes_dst - n->bytes_dst) / sec;
> + n->rate_pkts_src  = (pkts_src  - n->pkts_src)  / sec;
> + n->rate_pkts_dst  = (pkts_dst  - n->pkts_dst)  / sec;

I don't think we need the alignment here, it's readable enough without
the extra spaces.

> +}
> +
>  static inline struct flow_entry *flow_entry_xalloc(void)
>  {
>   return xzmalloc(sizeof(struct flow_entry));
> @@ -293,6 +333,7 @@ static void flow_list_new_entry(struct flow_list *fl, 
> struct nf_conntrack *ct)
>  
>   n->ct = nfct_clone(ct);
>  
> + flow_entry_update_time(n);
>   flow_entry_from_ct(n, ct);
>   flow_entry_get_extended(n);
>  
> @@ -736,25 +777,48 @@ static uint16_t presenter_get_port(uint16_t src, 
> uint16_t dst, bool is_tcp)
>  static char *bandw2str(double bytes, char *buf, size_t len)
>  {
>   if (bytes > 10.)
> - snprintf(buf, len, "%.1fG", bytes / 10.);
> + snprintf(buf, len, "%.1fGb", bytes / 10.);
>   else if (bytes > 100.)
> - snprintf(buf, len, "%.1fM", bytes / 100.);
> + snprintf(buf, len, "%.1fMb", bytes / 100.);
>   else if (bytes > 1000.)
> - snprintf(buf, len, "%.1fK", bytes / 1000.);
> + snprintf(buf, len, "%.1fKb", bytes / 1000.);
>   else
> - snprintf(buf, len, "%g", bytes);
> + snprintf(buf, len, "%g bytes", bytes);

Please split this change out into a separate preparatory patch as it is
not directly related to the rate change. This makes it easier to review
and bisect.

>  
>   return buf;
>  }
>  
> -static void presenter_print_counters(uint64_t bytes, uint64_t pkts, int 
> color)
> +static char *rate2str(double rate, char *buf, size_t len)
> +{
> + if (rate > 10.)
> + snprintf(buf, len, "%.1fGb/s", rate / 10.);
> + else if (rate > 100.)
> + snprintf(buf, len, "%.1fMb/s", rate / 100.);
> + else if (rate > 1000.)
> + snprintf(buf, len, "%.1fKb/s", rate / 1000.);
> + else
> + snprintf(buf, len, "%gB/s", rate);
> +
> + return buf;
> +}
> +
> +static void presenter_print_counters(uint64_t bytes, uint64_t pkts,
> +  double rate_bytes, double rate_pkts,
> +  int color)
>  {
>   char bytes_str[64];
>  
>   printw(" -> (");
>   attron(COLOR_PAIR(color));
> - printw("%"PRIu64" pkts, ", pkts);
> - printw("%s bytes", bandw2str(bytes, bytes_str, sizeof(bytes_str) - 1));
> + printw("%"PRIu64" 

Re: [netsniff-ng] netlink

[Tobias Klauser]

On 2015-10-17 at 11:08:22 +0200, Vadim Kochan  wrote:
> OK you can get changes from:
> https://github.com/vkochan/netsniff-ng/tree/netsniff_print_headers
> 
> I added -z,--headers option, you can find it in usage output.
> This option allows the following combinations:
> 
> --headers --hex
> --headers --ascii
> --headers --hex --ascii

Is it really necessary to indtroduce a new command-line option for this?
Couldn't we just dump the trailing, undissected data of the nlmsg in
hex by default (like we do e.g. with IP packets)?

Cheers
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] netlink

[Tobias Klauser]

On 2015-10-15 at 16:14:09 +0200, Geoff Ladwig  
wrote:
> Vadim,
> 
> Thanks for responding.
> 
> I have never found much use for the ASCII output... but would be happy
> either way.
> 
> Possibly a --headers options so you can individually select --header, --hex
> --ascii..?
> 
>  
> 
> I did not necessarily think this would be a new feature.. it seemed to work
> this way be default in an older version (0.5.7)
> 
> Running on a different machine with the older version below, you can see the
> header, asiii and hex all presented. This has no command line options. I'm
> guessing the display function shows things it has decoded and then shows the
> rest (the packet data in this case) in hex.

Exactly, that's the default behavior. But it looks like with the nlmsg
dissector (which wasn't included in 0.5.7 yet) this doesn't work.

As suggested in the reply to Vadim, I'd like to refrain from introducing
new command-line options and instead stick to the standard behavior
(dump disectable data as such and the rest as hex/ascii) for nlmsg as
well. Dumpping both the known headers as well as the _full_ packet in
hex/ascii doesn't seem very intuitive to me.

> The net link version seems to skip the last step - where it displays in hex
> the parts of the packet it hasn't decoded?

Yes, looks like it. I'll check whether I can come up with a fix.

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] netlink

[Tobias Klauser]

On 2015-10-19 at 14:09:19 +0200, Geoff Ladwig  
wrote:
> Tobias,
> 
> Either way works for me. 
> The issue I had was that the only way I could see all the data was with
> --hex , but then didn't get the headers- which are pretty handy!

Ok, great. Would it be possible for you to send me a pcap file with some
example traffic that shows the incorrect behaviour in netsniff-ng?

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] netlink

[Tobias Klauser]

On 2015-10-19 at 16:24:07 +0200, Geoff Ladwig  
wrote:
> Here is a .pcap generated using
> netsniff-ng --dev nlmon0 -o netlink.pcap

Perfect, thanks!

I just pushed a fix for this issue to the master branch. Could you
please check whether this fixes the issue for you?

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] netlink

[Tobias Klauser]

On 2015-10-19 at 17:38:03 +0200, Vadim Kochan <vadi...@gmail.com> wrote:
> On Mon, Oct 19, 2015 at 05:37:04PM +0200, Tobias Klauser wrote:
> > On 2015-10-19 at 12:43:33 +0200, vkochan <vadi...@gmail.com> wrote:
> > > On Mon, Oct 19, 2015 at 12:36:42PM +0200, Tobias Klauser wrote:
> > > > On 2015-10-15 at 16:14:09 +0200, Geoff Ladwig 
> > > > <glad...@verdantnetworks.com> wrote:
> > > > > Vadim,
> > > > > 
> > > > > Thanks for responding.
> > > > > 
> > > > > I have never found much use for the ASCII output... but would be happy
> > > > > either way.
> > > > > 
> > > > > Possibly a --headers options so you can individually select --header, 
> > > > > --hex
> > > > > --ascii..?
> > > > > 
> > > > >  
> > > > > 
> > > > > I did not necessarily think this would be a new feature.. it seemed 
> > > > > to work
> > > > > this way be default in an older version (0.5.7)
> > > > > 
> > > > > Running on a different machine with the older version below, you can 
> > > > > see the
> > > > > header, asiii and hex all presented. This has no command line 
> > > > > options. I'm
> > > > > guessing the display function shows things it has decoded and then 
> > > > > shows the
> > > > > rest (the packet data in this case) in hex.
> > > > 
> > > > Exactly, that's the default behavior. But it looks like with the nlmsg
> > > > dissector (which wasn't included in 0.5.7 yet) this doesn't work.
> > > 
> > > Sorry, seems I broke it ...
> > 
> > No problem! I fixed it in commit
> > f5f002fd8966b78ece5b4e1757e639379619670a. I would be glad if you could
> > check whether you see any problems with it.
> > 
> > Thanks!
> 
> Well I tested 'iw dev' with output:

Great, thanks for testing!

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] netsniff-ng: Fix print stats in silent mode

[Tobias Klauser]

On 2015-10-17 at 09:55:12 +0200, Vadim Kochan  wrote:
> RX stats were not printed because of wrong check on PRINT_NONE.
> 
> Signed-off-by: Vadim Kochan 
> Fixes: 5f94671f31c040f ("netsniff-ng: Show total rx stats for multi pcap 
> mode")

Applied, thanks Vadim.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] Stats differences between ifpps and netsniff-ng.

[Tobias Klauser]

On 2015-10-13 at 14:47:28 +0200, tmartin...@gmail.com <tmartin...@gmail.com> 
wrote:
> Le mardi 13 octobre 2015 14:02:45 UTC+2, Tobias Klauser a écrit :
> >
> > ifpps reports the NIC the cummulative stats since start of the system 
> > (i.e. the info from /proc/net/dev), so you'll probably also be seeing 
> > the stats from your previous attempts unless you reboot in between the 
> > trials (or for some NIC drivers reloading the driver module might have 
> > the same effect). 
> >
> > Cheers 
> > Tobias 
> >
> 
> Hello Tobias,
> 
> In my example I used the second columns of the csv output which corresponds 
> to "rx-bytes-per-t".
> 
> As far as I understand (I didn't check the source) it will be calculate 
> like:
> rx-bytes-per-t = n - n-1
> 
> where n is the value retrieved from /proc/net/dev and n-1 the previous 
> value retrieved (in my case t=1000 ms).

How periodic is the traffic you recieve?

How does it look if you average the values for RX bytes/t?

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] Stats differences between ifpps and netsniff-ng.

[Tobias Klauser]

On 2015-10-13 at 14:47:28 +0200, tmartin...@gmail.com <tmartin...@gmail.com> 
wrote:
> Le mardi 13 octobre 2015 14:02:45 UTC+2, Tobias Klauser a écrit :
> >
> > ifpps reports the NIC the cummulative stats since start of the system 
> > (i.e. the info from /proc/net/dev), so you'll probably also be seeing 
> > the stats from your previous attempts unless you reboot in between the 
> > trials (or for some NIC drivers reloading the driver module might have 
> > the same effect). 
> >
> > Cheers 
> > Tobias 
> >
> 
> Hello Tobias,
> 
> In my example I used the second columns of the csv output which corresponds 
> to "rx-bytes-per-t".
> 
> As far as I understand (I didn't check the source) it will be calculate 
> like:
> rx-bytes-per-t = n - n-1
> 
> where n is the value retrieved from /proc/net/dev and n-1 the previous 
> value retrieved (in my case t=1000 ms).
> 
> 
> So I don't understand why I need to reboot or reload the module for this 
> statistic (I get it if I was checking rx-bytes instead of rx-bytes-per-t 
> but I'm not).

Ah of course. Sorry, I wasn't reading your command careful enough.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] [PATCH 0/2] mmaped netlink packet

[Tobias Klauser]

On 2015-09-11 at 09:56:05 +0200, Ken-ichirou MATSUZAWA  
wrote:
>  Hi,
> 
> Thanks to Daniel, I can see mmaped netlink packet by netsniff-ng,
> but something is a little wrong. It seems that netsniff-ng can not
> get actual packet size. The output is like:
> 
>   >K ? 16360 1441873543s.15990ns #1
>[ NLMSG Family 12 (Netfilter), Len 916, Type 0x0300 (0x300), Flags 0x 
> (), Seq-Nr 0, PID 0 (
>   kernel) ]
>[ NLMSG Family 12 (Netfilter), Len 0, Type 0x (0x0), Flags 0x (), 
> Seq-Nr 0, PID 0 (ker
>   nel) ]
>[ Chr 
> 
>  
> 
> ...
>[ Hex  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
>  0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
> ... 
> 
> I think it's because mmaped skb size is equals to its frame size,
> may differ from actual size, and we can fix it by checking the next
> nlmsg len.
> 
> Would you review the following patches?

Looks good to me, series now applied. Thank you!

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] flowtop: man: Fix small typo of timestampinf

[Tobias Klauser]

On 2015-09-03 at 20:48:38 +0200, Vadim Kochan  wrote:
> From: Vadim Kochan 
> 
> Fix typo timestampinf -> timestamping
> 
> Signed-off-by: Vadim Kochan 

Sorry for introducing this with my "fixes" and thanks for fixing. Now
applied.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 2/3] flowtop: Enable flow timestamp on start

[Tobias Klauser]

On 2015-09-02 at 01:31:17 +0200, Vadim Kochan  wrote:
> From: Vadim Kochan 
> 
> Allow set start/stop timestamp for new flows by setting:
> 
> /proc/sys/net/netfilter/nf_conntrack_timestamp
> 
> on start and reset it on exit or panic.
> 
> Signed-off-by: Vadim Kochan 

Applied, thanks Vadim.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 1/3] flowtop: Show flow time duration

[Tobias Klauser]

On 2015-09-02 at 01:31:16 +0200, Vadim Kochan  wrote:
> From: Vadim Kochan 
> 
> Show human readable time since flow was created by Linux
> 
> Signed-off-by: Vadim Kochan 
> ---
>  flowtop.c | 38 ++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/flowtop.c b/flowtop.c
> index d988590..d073715 100644
> --- a/flowtop.c
> +++ b/flowtop.c
> @@ -41,6 +41,10 @@
>  #include "proc.h"
>  #include "sysctl.h"
>  
> +#ifndef NSEC_PER_SEC
> +#define NSEC_PER_SEC 10L
> +#endif
> +
>  struct flow_entry {
>   uint32_t flow_id, use, status;
>   uint8_t  l3_proto, l4_proto;
> @@ -750,6 +754,37 @@ static void presenter_print_counters(uint64_t bytes, 
> uint64_t pkts, int color)
>   printw(")");
>  }
>  
> +static void presenter_print_flow_entry_time(struct flow_entry *n)
> +{
> + int secs = n->timestamp_start / NSEC_PER_SEC;
> + int mns_sub, sec_sub;
> + int mns, hrs;
> + time_t now;
> +
> + time();
> + sec_sub = secs = now - secs;
> +
> + if (secs <= 0)
> + return;
> +
> + mns_sub = mns = secs / 60;
> + hrs = secs / 3600;
> +
> + if (secs > 60)
> + sec_sub = secs - mns * 60;
> + if (mns > 60)
> + mns_sub = mns - hrs * 60;
> +
> + printw(" [ time");
> + if (hrs > 0)
> + printw(" %dh", hrs);
> + if (mns_sub > 0)
> + printw(" %dm", mns_sub);
> + if (sec_sub > 0)
> + printw(" %ds", sec_sub);
> + printw(" ]");
> +}

This could be done a bit easier, using less variables and more straight
forward to read:

static void presenter_print_flow_entry_time(struct flow_entry *n)
{
int h, m, s;
time_t now;

time();

s = now - (n->timestamp_start / NSEC_PER_SEC);
if (s <= 0)
return;

h = s / 3600;
s -= h * 3600;
m = s / 60;
s -= m * 60;

printw(" [ time");
if (h > 0)
printw(" %dh", h);
if (m > 0)
printw(" %dm", m);
if (s > 0)
printw(" %ds", s);
printw(" ]");
}

I applied the patch with this version instead.

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH 1/3] flowtop: Show flow time duration

[Tobias Klauser]

On 2015-09-03 at 16:40:53 +0200, vkochan  wrote:
[...]
> What do you think if it is better to show time duration only by '-t' option ?
> Is it possible that time duration counting for each flow might stress someone 
> ?

In my opinion its fine like this, as it doesn't take much screen space
and the calculation of the duration isn't expensive.  If anyone feels
bothered by it, they can still submit a patch ;)

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] Re: [PATCH] netsniff-ng: Show total rx stats for multi pcap mode

[Tobias Klauser]

On 2015-08-24 at 20:37:03 +0200, Vadim Kochan vadi...@gmail.com wrote:
 From: Vadim Kochan vadi...@gmail.com
 
 Allow to collect rx stats for multiple pcap mode, by storing
 them in separated variables before switch to the next pcap file.
 
 It allows to have the one approach when dump for single or multiple
 pcap(s) mode.
 
 Signed-off-by: Vadim Kochan vadi...@gmail.com

Applied, thanks Vadim!

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [netsniff-ng] Can we specify the packet length during capturing the traffic?

[Tobias Klauser]

Hi Ivan

On 2015-08-21 at 05:20:33 +0200, Ivan Cheng ivancheng2...@gmail.com wrote:
 Hi Experts,
 
 Can we specify the packet length  during capturing the traffic?  This 
 feature allows us to just save the protocol information without user data. 
  It can avoid the save sensitive user data and save the disk spaces to 
 store more packets.

Currently this is not possible with netsniff-ng, but there's an open TODO
issue for it, see https://github.com/netsniff-ng/netsniff-ng/issues/94

I hope I'll find some time to work on this and the fixed number of
rotated files issue (#147) soon.

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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[netsniff-ng] [PULL] Pull request for netsniff-ng Debian packaging

[Tobias Klauser]

Hi Kartik

I made some minor changes to the Debian packaging of netsniff-ng, based off the
repo at git://anonscm.debian.org/collab-maint/netsniff-ng.git
(unfortunately I lost my account data for Alioth and I'm unable to
recover it since it is tied to an inactive e-mail address, thus I cannot
directly push the changes there).

Please pull if you see fit.

Thanks
Tobias

The following changes since commit 8edd93f06bd47dc4b33cad06b2a6a266cdd0cc21:

  New upstream version, Updated S-V to 3.9.6, Updated copyright (2015-05-09 
20:22:49 +0530)

are available in the git repository at:

  https://github.com/tklauser/pkg-netsniff-ng.git for-kartik

for you to fetch changes up to 36d6176dcea2de4f1752e402eac7b907507534b5:

  Use verbose build to make compiler flags visible in buildd logs (2015-08-20 
09:14:16 +0200)


Tobias Klauser (3):
  Remove cmake from Build-Depends
  Adjust Vcs-Browser path
  Use verbose build to make compiler flags visible in buildd logs

 debian/changelog | 10 ++
 debian/control   |  3 +--
 debian/rules |  2 +-
 3 files changed, 12 insertions(+), 3 deletions(-)

-- 
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 netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.