On Wed, Apr 28, 2021 at 10:49 AM Christian Mauderer <o...@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.maude...@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@rtems.org > >>> http://lists.rtems.org/mailman/listinfo/devel > >>> > >> > >> -- > >> -------------------------------------------- > >> embedded brains GmbH > >> Herr Christian MAUDERER > >> Dornierstr. 4 > >> 82178 Puchheim > >> Germany > >> email: christian.maude...@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@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
