Re: [tcpdump-workers] hello

2012-09-05 Thread George Bakos
Lovgate worm.

On Wed, 5 Sep 2012 17:07:01 +0800
rene.p...@ftw.at wrote:

> Mail  failed.  For further assistance, please contact!
> 


-- 
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


[tcpdump-workers] Modular arithmetic

2012-09-05 Thread George Bakos
I don't see any discussion regarding adding modular operations to
pcap, i.e. "header[offset:width] % 4 != 0". I've put together a patch
that compiles & honors that (at least on the few systems I've tried),
but was wondering if there were any fundamental reason to avoid it?

Thanks.
g
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] Modular arithmetic

2012-09-06 Thread George Bakos
Your recommended approach certainly works:

$  tcpdump -nvr /tmp/DG2-test2 '((ip[2:2] - 20) - (((ip[2:2] - 20) /
5) * 5)) != 0 && ip[6] & 0x20 = 0x20' 
reading from file /tmp/DG2-test2, link-type EN10MB (Ethernet)
19:01:51.270202 IP (tos 0x0, ttl 64, id 1, offset 40, flags [+],
proto ICMP (1), length 61) 192.168.11.5 > 192.168.11.46: ip-proto-1

(000) ldh  [12]
(001) jeq  #0x800   jt 2jf 16
(002) ldh  [16]
(003) sub  #20
(004) st   M[2]
(005) ldh  [16]
(006) sub  #20
(007) div  #5
(008) mul  #5
(009) tax  
(010) ld   M[2]
(011) jeq  xjt 16   jf 12
(012) ldb  [20]
(013) and  #0x20
(014) jeq  #0x20jt 15   jf 16
(015) ret  #65535
(016) ret  #0

(obviously optimized)

vs:

$  tcpdump -nvr /tmp/DG2-test2 '(ip[2:2] - 20) % 5 != 0 && ip[6] &
0x20 = 0x20' 

reading from file /tmp/DG2-test2, link-type EN10MB (Ethernet)
19:01:51.270202 IP (tos 0x0, ttl 64, id 1, offset 40, flags [+],
proto ICMP (1), length 61) 192.168.11.5 > 192.168.11.46: ip-proto-1

(000) ldh  [12]
(001) jeq  #0x800   jt 2jf 10
(002) ldh  [16]
(003) sub  #20
(004) mod  #5
(005) jeq  #0x0 jt 10   jf 6
(006) ldb  [20]
(007) and  #0x20
(008) jeq  #0x20jt 9jf 10
(009) ret  #65535
(010) ret  #0

On Wed, 5 Sep 2012 16:19:11 -0700
Guy Harris  wrote:

> 
> On Sep 5, 2012, at 2:39 PM, George Bakos wrote:
> 
> > I don't see any discussion regarding adding modular operations to
> > pcap, i.e. "header[offset:width] % 4 != 0". I've put together a patch
> > that compiles & honors that (at least on the few systems I've tried),
> 
> Does it work if the right-hand side of the % operator isn't a constant power 
> of 2 (e.g., by dividing the LHS by the RHS, multiplying the result by the 
> RHS, and subtracting the result from the LHS)?
> ___
> tcpdump-workers mailing list
> tcpdump-workers@lists.tcpdump.org
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


-- 
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] [PATCH net-next] filter: add MOD operation

2012-09-08 Thread George Bakos
Here's a patch to libpcap-1.3 to test against. I still need to
include changes to man pages.

g

On Sat, 08 Sep 2012 10:03:35 +0200
Eric Dumazet  wrote:

> From: Eric Dumazet 
> 
> On Fri, 2012-09-07 at 20:03 -0700, Andi Kleen wrote:
> > On Fri, Sep 07, 2012 at 07:49:10AM +, George Bakos wrote:
> > > Gents,
> > > Any fundamental reason why the following (, etc.) shouldn't be
> > > included in net/core/filter.c?
> > > 
> > > case BPF_S_ALU_MOD_X:
> > > if (X == 0)
> > > return 0;
> > > A %= X;
> > > continue;
> > 
> > Copying netdev.
> > 
> > In principle no reason against it, but you may need to update
> > the various BPF JITs too that Linux now has too.
> 
> Hi Andi, thanks for the forward
> 
> In recent commit ffe06c17afbb was added ALU_XOR_X,
> so we could add ALU_MOD_X as well.
> 
> ALU_MOD_K is a bit more complex as we cant use an ancillary, and must
> instead use a new BPF_OP code :
> 
> /* alu/jmp fields */
> #define BPF_OP(code)((code) & 0xf0)
> #define BPF_ADD 0x00
> #define BPF_SUB 0x10
> #define BPF_MUL 0x20
> #define BPF_DIV 0x30
> #define BPF_OR  0x40
> #define BPF_AND 0x50
> #define BPF_LSH 0x60
> #define BPF_RSH 0x70
> #define BPF_NEG 0x80
> 
> So I guess we could use
> 
> #define BPF_MOD 0x90
> 
> About the various arches JIT, there is no hurry :
> We can update them later.
> 
> At JIT 'compile' time, if we find a not yet handled instruction, we fall
> back to the net/core/filter.c interpreter.
> 
> If the following patch is accepted, I'll do the x86 part as a followup.
> 
> Thanks !
> 
> [PATCH net-next] filter: add MOD operation
> 
> Add a new ALU opcode, to compute a modulus.
> 
> Commit ffe06c17afbbb used an ancillary to implement XOR_X,
> but here we reserve one of the available ALU opcode to implement both
> MOD_X and MOD_K
> 
> Signed-off-by: Eric Dumazet 
> Suggested-by: George Bakos 
> Cc: Jay Schulist 
> Cc: Jiri Pirko 
> Cc: Andi Kleen 
> ---
>  include/linux/filter.h |4 
>  net/core/filter.c  |   15 +++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index 82b0135..3cf5fd5 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -74,6 +74,8 @@ struct sock_fprog { /* Required for SO_ATTACH_FILTER. */
>  #define BPF_LSH 0x60
>  #define BPF_RSH 0x70
>  #define BPF_NEG 0x80
> +#define  BPF_MOD 0x90
> +
>  #define BPF_JA  0x00
>  #define BPF_JEQ 0x10
>  #define BPF_JGT 0x20
> @@ -196,6 +198,8 @@ enum {
>   BPF_S_ALU_MUL_K,
>   BPF_S_ALU_MUL_X,
>   BPF_S_ALU_DIV_X,
> + BPF_S_ALU_MOD_K,
> + BPF_S_ALU_MOD_X,
>   BPF_S_ALU_AND_K,
>   BPF_S_ALU_AND_X,
>   BPF_S_ALU_OR_K,
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 907efd2..fbe3a8d 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -167,6 +167,14 @@ unsigned int sk_run_filter(const struct sk_buff *skb,
>   case BPF_S_ALU_DIV_K:
>   A = reciprocal_divide(A, K);
>   continue;
> + case BPF_S_ALU_MOD_X:
> + if (X == 0)
> + return 0;
> + A %= X;
> + continue;
> + case BPF_S_ALU_MOD_K:
> + A %= K;
> + continue;
>   case BPF_S_ALU_AND_X:
>   A &= X;
>   continue;
> @@ -469,6 +477,8 @@ int sk_chk_filter(struct sock_filter *filter, unsigned 
> int flen)
>   [BPF_ALU|BPF_MUL|BPF_K]  = BPF_S_ALU_MUL_K,
>   [BPF_ALU|BPF_MUL|BPF_X]  = BPF_S_ALU_MUL_X,
>   [BPF_ALU|BPF_DIV|BPF_X]  = BPF_S_ALU_DIV_X,
> + [BPF_ALU|BPF_MOD|BPF_K]  = BPF_S_ALU_MOD_K,
> + [BPF_ALU|BPF_MOD|BPF_X]  = BPF_S_ALU_MOD_X,
>   [BPF_ALU|BPF_AND|BPF_K]  = BPF_S_ALU_AND_K,
>   [BPF_ALU|BPF_AND|BPF_X]  = BPF_S_ALU_AND_X,
>   [BPF_ALU|BPF_OR|BPF_K]   = BPF_S_ALU_OR_K,
> @@ -531,6 +541,11 @@ int sk_chk_filter(struct sock_filter *filter, unsigned 
> int flen)
>   return -EINVAL;
>