On Wed, Apr 28, 2021 at 3:26 PM Chris Johns <chr...@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 <chr...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel