Subject: Re: pktgen patch available for perusal.

From: jamal <[email-masked]>
Date: Sat, 04 Nov 2006 13:10:55 -0500

On Sat, 2006-04-11 at 09:29 -0800, Ben Greear wrote:
> jamal wrote:
   
> Please do send a script.  I match based on this method below.   Probably 
> you only
> need the part that checks for the MAGIC, 

What i do in my case is send to the SUT to UDP port 9. The SUT loops
back the packet to me after processing and i just have a simple check in
the traffic generator of:

a) Packet = IPV4, IP address matches what i want, port =9, 
b) If this matches i  account and drop it. This means all other traffic
(like ssh etc goes through fine).

I dont really need to check for length because _i know_ udp port 9 to
the SUT is test traffic.

For such a setup, the script would be as simple as (assuming SUT hooked
to eth0):

--
#interested in incoming packets on eth0
tc qdisc add dev eth0 ingress
#interested in packets coming from SUT(10.0.0.21) on UDP port 9
tc filter add dev eth0 parent ffff: protocol ip prio 6 u32 \
match ip src 10.0.0.21/32 \
match udp port 9 0xffff \
flowid 1:16 \
action drop
---

When you do a listing of this filter you will see accounting info.
You list by saying:
---
tc -s filter ls dev eth0 parent ffff:
---

You can ofcourse add many of these based on other header info.

It seems to me your magic header is inside the UDP packet, correct?
In that case you will have to play with matches since you can specify
arbitraty offsets and values inside the packet.

Of course you can do this from your application instead of using tc.
I think that will be the best place to control this and sync with
pktgen sending.

> the rest can be in a method 
> called after you match in your script?
> 

If the packet/byte counters that the drop action provides are not good
enough, you can write yourself a little module that will do the
accounting the way you want it. For example this will be necessary to
the out-of-sequence cheques below. Timestamps are already being updated
Look at net/sched/act_simple.c and its associated user space code in
iproute2.

Now, Ben - are you listening really this time or am i wasting my time
for the nth time giving you all these details? ;->

If you are listening then start with:

1) Do a simple test with just udp traffic as above, doing simple
accounting. This helps you to get a feel on how things work.
2) modify the matching rules to match your magic cookie
3) write a simple action invoked by your matching rules and use tc to
add it to the policy.
4) integrate in your app now that you know what you are doing.

If you follow these steps or a variant-of i will spend time and help.

cheers,
jamal