tcpreplay for testing network stacks

[Vijay Kumar Banerjee]

On Wed, Apr 28, 2021 at 10:49 AM Christian Mauderer <oss at c-mauderer.de> wrote:
>
> Hello Vijay,
>
> On 28/04/2021 18:25, Vijay Kumar Banerjee wrote:
> > On Wed, Apr 28, 2021 at 12:41 AM Christian MAUDERER
> > <christian.mauderer at embedded-brains.de> wrote:
> >>
> >> Hello Vijay,
> >>
> >> Am 27.04.21 um 18:48 schrieb Vijay Kumar Banerjee:
> >>> Hi,
> >>>
> >>> 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.
> >>
> >> Sounds like an interesting tool.
> >>
> >>>
> >>> 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.
> >>
> >> The more difficult problem could be the missing Mac and FreeBSD support.
> >>
> > That's a good point.
> >
> >> What would be the advantage of having tcpreply in rtems-tools? Do you
> >> want to use it for automated tests?
> >>
> > Yes. I was thinking about capturing the pcap format packets in
> > temporary files and then running tcpreplay to check for any network
> > issues. I haven't planned exactly how that will be implemented but
> > roughly this is the idea.
> >
>
> In what form would you automate that? Some test case in RTEMS or some
> special repository? I assume that you need some special setup for
> specific (simulator) targets anyway, don't you? So a general purpose
> test for all targets will be difficult.
>
I was not thinking about a special repository. It would be nice to
have it as test case or as an rtems-test config where the script will
capture the packets and feed them to tcpreplay.

> If it is about testing the stacks and not the drivers, it might would be
> possible to write some kind of dummy network driver that can read pcap
> format (or some other raw packet format) directly and hands the packets
> to the network stack. Such a driver maybe could even provide packets to
> a test frame again so that you can check responses.
>
The objective is to test the stacks. The dummy network driver sounds
like a great idea, thanks. I'll explore this direction more.

> Best regards
>
> Christian
>
> >> Best regards
> >>
> >> Christian
> >>
> >>>
> >>> Source repository:https://github.com/appneta/tcpreplay
> >>> <https://github.com/appneta/tcpreplay>
> >>>
> >>> Thoughts and suggestions are much appreciated.
> >>>
> >>>
> >>> Best regards,
> >>> Vijay
> >>>
> >>> _______________________________________________
> >>> devel mailing list
> >>> devel at rtems.org
> >>> http://lists.rtems.org/mailman/listinfo/devel
> >>>
> >>
> >> --
> >> --------------------------------------------
> >> embedded brains GmbH
> >> Herr Christian MAUDERER
> >> Dornierstr. 4
> >> 82178 Puchheim
> >> Germany
> >> email: christian.mauderer at embedded-brains.de
> >> phone: +49-89-18 94 741 - 18
> >> fax:   +49-89-18 94 741 - 08
> >>
> >> Registergericht: Amtsgericht München
> >> Registernummer: HRB 157899
> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> >> Unsere Datenschutzerklärung finden Sie hier:
> >> https://embedded-brains.de/datenschutzerklaerung/
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >