On Wed, Apr 28, 2021 at 3:27 PM Chris Johns <chr...@rtems.org> wrote: > > > > On 29/4/21 3:00 am, Vijay Kumar Banerjee wrote: > > 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. > > Capture from where? How do these traces deal with the differences in networks? more tools :). What I was attempting is tcpdump to get the pcap and then tcpreplay. I was basically in search of some way to effectively test the network stacks.
> Does tcpreply rewrite various fields, for example a DHCP server response? I > suspect it does not. > I'm not sure. > Tcpreplay may work out to be a good tool we use but I think there needs to be > some more ground work to see if you can "virtualize" a network. If you can do > this you control the arena the devices operate in and all the characteristics > and then play back would be possible and portable. > > VDE may be an interesting part of this. I seem to remember it has a DHCP > server > so if you use this with a tap that VDE manages rtems-test could use that > interface. > That sounds like a great idea. > A tricky area to look into is if a VDE port can map to a physical port? If > this > can be done you could mix simulation and real hardware and that would be > amazing > to have. > I'll search about this. Thanks for the great ideas, I'm indeed getting some direction. Best regards, Vijay > >> 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. > > I prefer real drivers are used as it lets us extend testing to VLAN and > multicast (driver hashes and filter testing). > > A solution needs to find a suitable lowest common denominator. This means > hardware and simulation and possibly the different networking stack options > we have. > > Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel