[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190704202909.gmggf3agxjgvyjsj@x220t>
Date: Thu, 4 Jul 2019 16:29:09 -0400
From: Alexander Aring <aring@...atatu.com>
To: Lucas Bates <lucasb@...atatu.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org, jhs@...atatu.com,
xiyou.wangcong@...il.com, jiri@...nulli.us, mleitner@...hat.com,
vladbu@...lanox.com, dcaratti@...hat.com, kernel@...atatu.com
Subject: Re: [PATCH v2 net-next 3/3] tc-testing: introduce scapyPlugin for
basic traffic
Hi,
On Wed, Jul 03, 2019 at 08:45:02PM -0400, Lucas Bates wrote:
> The scapyPlugin allows for simple traffic generation in tdc to
> test various tc features. It was tested with scapy v2.4.2, but
> should work with any successive version.
>
> In order to use the plugin's functionality, scapy must be
> installed. This can be done with:
> pip3 install scapy
>
> or to install 2.4.2:
> pip3 install scapy==2.4.2
>
> If the plugin is unable to import the scapy module, it will
> terminate the tdc run.
>
> The plugin makes use of a new key in the test case data, 'scapy'.
> This block contains three other elements: 'iface', 'count', and
> 'packet':
>
> "scapy": {
> "iface": "$DEV0",
> "count": 1,
> "packet": "Ether(type=0x800)/IP(src='16.61.16.61')/ICMP()"
> },
>
> * iface is the name of the device on the host machine from which
> the packet(s) will be sent. Values contained within tdc_config.py's
> NAMES dict can be used here - this is useful if paired with
> nsPlugin
> * count is the number of copies of this packet to be sent
> * packet is a string detailing the different layers of the packet
> to be sent. If a property isn't explicitly set, scapy will set
> default values for you.
>
> Layers in the packet info are separated by slashes. For info about
> common TCP and IP properties, see:
> https://blogs.sans.org/pen-testing/files/2016/04/ScapyCheatSheet_v0.2.pdf
>
> Caution is advised when running tests using the scapy functionality,
> since the plugin blindly sends the packet as defined in the test case
> data.
>
> See creating-testcases/scapy-example.json for sample test cases;
> the first test is intended to pass while the second is intended to
> fail. Consider using the matchJSON functionality for verification
> when using scapy.
>
Is there a way to introduce thrid party scapy level descriptions which
are not upstream yet?
- Alex
Powered by blists - more mailing lists