tcpreplay for testing network stacks

Vijay Kumar Banerjee vijay at rtems.org
Wed Apr 28 22:43:12 UTC 2021


On Wed, Apr 28, 2021 at 3:26 PM Chris Johns <chrisj at rtems.org> wrote:
>
> On 29/4/21 2:31 am, Vijay Kumar Banerjee wrote:
> > On Wed, Apr 28, 2021 at 12:45 AM Chris Johns <chrisj at rtems.org> wrote:
> >>
> >> On 28/4/21 2:48 am, Vijay Kumar Banerjee wrote:
> >>> I came across the tcpreplay tool and it looks like a nice tool for testing the
> >>> network stacks. It can be used to capture network traffic and then play it back,
> >>> this will help with testing the network packets from different network stacks.
> >>>
> >>> My proposal is to add the tcpreply as a host-side tool in rtems-tools and use it
> >>> with the network interface where the network application is running. The only
> >>> issue that I see with the whole idea is that the tcpreplay is GPLv3 licensed.
> >>> Will that be compatible for rtems-tools? The github repository says that it's
> >>> compatible with UNIX and Windows with cygwin.
> >>>
> >>> Source repository:https://github.com/appneta/tcpreplay
> >>> <https://github.com/appneta/tcpreplay>
> >>>
> >>> Thoughts and suggestions are much appreciated.
> >>
> >> It is GPLv3 so it cannot be imported as source. It can be referenced as a
> >> command if available for the host.
> >>
> > Ok.
> >
> >> I also suggest you investigate VDE with qemu. This is what I use to avoid being
> >> root.
> >>
> > VDE looks great, I haven't tried it before. Thanks for the suggestion!
> > I'll try this out.
>
> No problem. Amar put me on to it years ago. I like it because I can run a few
> qemu networked sessions and I do not need to be root to do this. My host set up
> is simple...
>
> From /etc/rc.conf:
>
> cloned_interfaces="bridge0 tap0 tap1 tap2"
> autobridge_interfaces="bridge0"
> ifconfig_bridge0="inet 10.10.5.2 netmask 255.255.255.0"
> autobridge_bridge0="re0.3 tap0 tap1 tap2"
>
> $ cat vde-start
> #! /bin/sh
> #
> # vdeterm /tmp/mgmt1
> #
> sysctl net.link.tap.user_open=1
> sysctl net.link.tap.up_on_open=1
> chmod 660 /dev/tap0
> vde_switch -d -s /tmp/vde1 -M /tmp/mgmt1 -tap tap0 -m 660 --mgmtmode 660
>
> Note, I internally run a bridge that VDE attaches to and all this is layer 2.
> The bridge is connected to a VLAN my engineering network runs on. You have to
> expect varying levels of complexity in user networks.
>
Thank you for the detailed configuration. It certainly looks nicer
compared to running wireshark using root.

> > Can write some rtems-test recipes with VDE to
> > automate the run? will that be feasible/possible?
>
> This depends on the type of testing you are looking to perform and the type of
> network architecture you are considering. My set up lets a qemu session see my
> network. I am bridging across it via a single tap that is created when the OS
> boots. I have attached some slides I put together last year on this topic.
>
The slides are interesting, thanks.

> The challenge is keeping the network infrastructure needed to a minimum, a
> simple configuration, support for hardware and simulation targets and agnostic
> network support.
>
I would certainly need to try it out for some manual runs first and
then I might start to look at how can we come up with a minimal
configuration for the automated testing.


> Chris


More information about the devel mailing list